idnits 2.17.1 draft-ietf-idmr-dvmrp-v3-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 18 characters in excess of 72. ** The abstract seems to contain references ([Deer90], [Wait88]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 48: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 49: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 134: '... MUST be set to 1....' RFC 2119 keyword, line 368: '...e. The checksum MUST be calculated up...' RFC 2119 keyword, line 369: '...transmission and MUST be validated on ...' (38 more instances...) == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC1075, but the abstract doesn't seem to directly say this. It does mention RFC1075 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 326 has weird spacing: '...ets are encap...' == Line 359 has weird spacing: '...aft Ack for ...' == Line 1865 has weird spacing: '...for the purpo...' -- 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 (October 22, 2003) is 7464 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: 'RFC-2119' is mentioned on line 51, but not defined -- Looks like a reference, but probably isn't: '00' on line 737 ** Downref: Normative reference to an Informational RFC: RFC 1071 (ref. 'Brad88') -- Possible downref: Non-RFC (?) normative reference: ref. 'Deer90' -- Possible downref: Non-RFC (?) normative reference: ref. 'Deer91' -- Possible downref: Non-RFC (?) normative reference: ref. 'Fenn00' ** Obsolete normative reference: RFC 1519 (ref. 'Full93') (Obsoleted by RFC 4632) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. 'Han94a') ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. 'Han94b') ** Obsolete normative reference: RFC 2401 (ref. 'Ken98a') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. 'Ken98b') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2932 (ref. 'McCl00') (Obsoleted by RFC 5132) -- Possible downref: Non-RFC (?) normative reference: ref. 'Perl92' ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. 'Rekh93') -- Possible downref: Non-RFC (?) normative reference: ref. 'Reyn94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Thal97' ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. 'Wait88') Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 T. Pusateri 2 INTERNET DRAFT Juniper Networks 3 Obsoletes: RFC 1075 October 22, 2003 4 draft-ietf-idmr-dvmrp-v3-11 Expires: April 22, 2004 6 Distance Vector Multicast Routing Protocol 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 DVMRP is an Internet routing protocol that provides an efficient 32 mechanism for connection-less datagram delivery to a group of hosts 33 across an internetwork. It is a distributed protocol that dynamically 34 generates IP Multicast delivery trees using a technique called 35 Reverse Path Multicasting (RPM) [Deer90]. This document is an update 36 to Version 1 of the protocol specified in RFC 1075 [Wait88]. 38 1. Introduction 40 DVMRP uses a distance vector distributed routing algorithm in order 41 to build per-source-group multicast delivery trees. A good 42 introduction to distance vector routing can be found in [Perl92]. 43 The application of distance vector routing to multicast tree 44 formulation is described in [Deer91]. 46 1.1. Requirements Terminology 48 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 49 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 50 document, are to be interpreted as described in [RFC-2119]. 52 1.2. Reverse Path Multicasting 54 Datagrams follow multicast delivery trees from a source to all 55 members of a multicast group [Deer89], replicating the packet only at 56 necessary branches in the delivery tree. The trees are calculated and 57 updated dynamically to track the membership of individual groups. 58 When a datagram arrives on an interface, the reverse path to the 59 source of the datagram is determined by examining a DVMRP routing 60 table of known source networks. If the datagram arrives on an 61 interface that would be used to transmit datagrams back to the 62 source, then it is forwarded to the appropriate list of downstream 63 interfaces. Otherwise, it is not on the optimal delivery tree and 64 should be discarded. In this way duplicate packets can be filtered 65 when loops exist in the network topology. The source specific 66 delivery trees are automatically pruned back as group membership 67 changes or routers determine that no group members are present. This 68 keeps the delivery trees to the minimum branches necessary to reach 69 all of the group members. New sections of the tree can also be added 70 dynamically as new members join the multicast group by grafting the 71 new sections onto the delivery trees. 73 1.3. Tunnel Encapsulation 75 Because not all IP routers support native multicast routing, DVMRP 76 includes direct support for tunneling IP Multicast datagrams through 77 routers. The IP Multicast datagrams are encapsulated in unicast IP 78 packets and addressed to the routers that do support native multicast 79 routing. DVMRP treats tunnel interfaces in an identical manner to 80 physical network interfaces. 82 In previous implementations, DVMRP protocol messages were sent un- 83 encapsulated to the unicast tunnel endpoint address. While this was 84 more direct, it increased the complexity of firewall configuration. 85 The most noticeable change in this specification regarding tunnels is 86 that all DVMRP protocol messages should be sent encapsulated across 87 the tunnel. Previously, protocol messages were sent un-encapsulated 88 directly to the tunnel endpoint. See Appendix C for backward 89 compatibility issues. 91 Note: All protocol messages sent on point-to-point links (including 92 tunnels) should use a destination address of All-DVMRP-Routers. This 93 change will allow the protocol messages to be forwarded across 94 multicast-only tunnels without making encapsulation and decapsulation 95 difficult. 97 In practice, tunnels typically use either IP-IP [Perk96] or Generic 98 Routing Encapsulation (GRE) [Han94a,Han94b], although, other 99 encapsulation methods are acceptable. 101 1.4. Document Overview 103 Section 2 provides an overview of the protocol and the different 104 message types exchanged by DVMRP routers. Those who wish to gain a 105 general understanding of the protocol but are not interested in the 106 more precise details may wish to only read this section. Section 3 107 explains the detailed operation of the protocol to accommodate 108 developers needing to provide inter-operable implementations. 109 Included in Appendix A, is a summary of the DVMRP parameters. A 110 section on DVMRP support for tracing and troubleshooting is the topic 111 of Appendix B. Finally, a short DVMRP version compatibility section 112 is provided in Appendix C to assist with backward compatibility 113 issues. 115 2. Protocol Overview 117 DVMRP can be summarized as a "broadcast & prune" multicast routing 118 protocol. It builds per-source broadcast trees based upon routing 119 exchanges, then dynamically creates per-source-group multicast 120 delivery trees by pruning (removing branches from) the source's 121 truncated broadcast tree. It performs Reverse Path Forwarding checks 122 to determine when multicast traffic should be forwarded to downstream 123 interfaces. In this way, source-rooted shortest path trees can be 124 formed to reach all group members from each source network of 125 multicast traffic. 127 2.1. Neighbor Discovery 129 Neighbor DVMRP routers are discovered dynamically by sending Neighbor 130 Probe Messages on local multicast capable network interfaces and 131 tunnel pseudo interfaces. These messages are sent periodically to the 132 All-DVMRP-Routers [Reyn94] IP Multicast group address. (See Appendix 133 C for backwards compatibility issues.) The IP TTL of these messages 134 MUST be set to 1. 136 Each Neighbor Probe message contains the list of Neighbor DVMRP 137 routers for which Neighbor Probe messages have been received on that 138 interface. In this way, Neighbor DVMRP routers can ensure that they 139 are seen by each other. 141 Once you have received a Probe from a neighbor that contains your 142 address in the neighbor list, you have established a two-way neighbor 143 adjacency with this router. 145 2.2. Source Location 147 When an IP Multicast datagram is received by a router running DVMRP, 148 it first looks up the source network in the DVMRP routing table. The 149 interface on which the best route to the source of the datagram was 150 received is called the upstream (also called RPF) interface. If the 151 datagram arrived on the correct upstream interface, then it is a 152 candidate for forwarding to one or more downstream interfaces. If the 153 datagram did not arrive on the anticipated upstream interface, it is 154 discarded. This check is known as a reverse path forwarding check and 155 must be performed by all DVMRP routers. 157 In order to ensure that all DVMRP routers have a consistent view of 158 the path back to a source, a routing table is propagated to all DVMRP 159 routers as an integral part of the protocol. Each router advertises 160 the network number and mask of the interfaces it is directly 161 connected to as well as relaying the routes received from neighbor 162 routers. DVMRP requires an interface metric to be configured on all 163 physical and tunnel interfaces. When a route is received, the metric 164 of the interface over which the datagram was received must be added 165 to the metric of the route being advertised in the route report 166 message. This adjusted metric should be used when comparing metrics 167 to determine the best upstream neighbor. 169 Although there is certainly additional overhead associated with 170 propagating a separate DVMRP routing table, it does provide two nice 171 features. First, since all DVMRP routers are exchanging the same 172 routes, there are no inconsistencies between routers when determining 173 the upstream interface (aside from normal convergence issues related 174 to distance vector routing protocols). By placing the burden of 175 synchronization on the protocol as opposed to the network manager, 176 DVMRP reduces the risk of creating routing loops or black holes due 177 to disagreement between neighbor routers on the upstream interface. 179 Second, by propagating its own routing table, DVMRP makes it 180 convenient to have separate paths for unicast versus multicast 181 datagrams. Although, ideally, many network managers would prefer to 182 keep their unicast and multicast traffic aligned, tunneled multicast 183 topologies may prevent this causing the unicast and multicast paths 184 to diverge. Additionally, service providers may prefer to keep the 185 unicast and multicast traffic separate for routing policy reasons as 186 they experiment with IP multicast routing and begin to offer it as a 187 service. 189 2.3. Dependent Downstream Routers 191 In addition to providing a consistent view of source networks, the 192 exchange of routes in DVMRP provides one other important feature. 193 DVMRP uses the route exchange as a mechanism for upstream routers to 194 determine if any downstream routers depend on them for forwarding 195 from particular source networks. DVMRP accomplishes this by using a 196 technique called "Poison Reverse". If a downstream router selects an 197 upstream router as the best next hop to a particular source network, 198 this is indicated by echoing back the route on the upstream interface 199 with a metric equal to the original metric plus infinity. When the 200 upstream router receives the report and sees a metric that lies 201 between infinity and twice infinity, it can then add the downstream 202 router from which it received the report to a list of dependent 203 routers for this source. 205 This list of dependent routers per source network built by the 206 "Poison Reverse" technique will provide the foundation necessary to 207 determine when it is appropriate to prune back the IP source specific 208 multicast trees. 210 2.4. Designated Forwarder 212 When two or more multicast routers are connected to a multi-access 213 network, it could be possible for duplicate packets to be forwarded 214 on the network (one copy from each router). DVMRP prevents this 215 possibility by electing a forwarder for each source as a side effect 216 of its route exchange. When two routers on a multi-access network 217 exchange source networks, each of the routers will know the others 218 metric back to each source network. Therefore, of all the DVMRP 219 routers on a shared network, the router with the lowest metric to a 220 source network is responsible for forwarding data on to the shared 221 network. If two or more routers have an equally low metric, the 222 router with the lowest IP address becomes the designated forwarder 223 for the network. In this way, DVMRP does an implicit designated 224 forwarder election for each source network on each downstream 225 interface. 227 2.5. Building Multicast Trees 229 As previously mentioned, when an IP multicast datagram arrives, the 230 upstream interface is determined by looking up the interface on which 231 the best route to the source of the datagram was received. If the 232 upstream interface is correct, then a DVMRP router will forward the 233 datagram to a list of downstream interfaces. 235 2.5.1. Adding Local Group Members 237 The IGMP local group database is maintained by all IP multicast 238 routers on each physical, multicast capable network [Cain02]. If the 239 destination group address is listed in the local group database, and 240 the router is the designated forwarder for the source, then the 241 interface is included in the list of downstream interfaces. If there 242 are no group members on the interface, then the interface is removed 243 from the outgoing interface list. 245 2.5.2. Adding Interfaces with Neighbors 247 Initially, all interfaces with downstream dependent neighbors should 248 be included in the downstream interface list when a forwarding cache 249 entry is first created. This allows the downstream routers to be 250 aware of traffic destined for a particular (source network, group) 251 pair. The downstream routers will then have the option to send prunes 252 and subsequent grafts for this (source network, group) pair as 253 requirements change from their respective downstream routers and 254 local group members. 256 2.6. Pruning Multicast Trees 258 As mentioned above, routers at the edges will remove their interfaces 259 that have no group members associated with an IP multicast datagram. 260 If a router removes all of its downstream interfaces, it notifies the 261 upstream router that it no longer wants traffic destined for a 262 particular (source network, group) pair. This is accomplished by 263 sending a DVMRP Prune message upstream to the router it expects to 264 forward datagrams from a particular source. 266 Recall that a downstream router will inform an upstream router that 267 it depends on the upstream router to receive datagrams from 268 particular source networks by using the "Poison Reverse" technique 269 during the exchange of DVMRP routes. This method allows the upstream 270 router to build a list of downstream routers on each interface that 271 are dependent upon it for datagrams from a particular source network. 272 If the upstream router receives prune messages from each one of the 273 dependent downstream routers on an interface, then the upstream 274 router can in turn remove this interface from its downstream 275 interface list. If the upstream router is able to remove all of its 276 downstream interfaces in this way, it can then send a DVMRP Prune 277 message to its upstream router. This continues until the unneeded 278 branches are removed from the delivery tree. 280 In order to remove old prune state information for (source network, 281 group) pairs that are no longer active, it is necessary to limit the 282 life of a prune and periodically resume the broadcasting procedure. 283 The prune message contains a prune lifetime, indicating the length of 284 time that the prune should remain in effect. When the prune lifetime 285 expires, the interface is joined back onto the multicast delivery 286 tree. If unwanted multicast datagrams continue to arrive, the prune 287 mechanism will be re-initiated and the cycle will continue. If all 288 of the downstream interfaces are removed from a multicast delivery 289 tree causing a DVMRP Prune message to be sent upstream, the lifetime 290 of the prune sent must be equal to the minimum of the remaining 291 lifetimes of the received prunes. 293 2.7. Grafting Multicast Trees 295 Once a tree branch has been pruned from a multicast delivery tree, 296 packets from the corresponding (source network, group) pair will no 297 longer be forwarded. However, since IP multicast supports dynamic 298 group membership, hosts may join a multicast group at any time. In 299 this case, DVMRP routers use Grafts to cancel the prunes that are in 300 place from the host back on to the multicast delivery tree. A router 301 will send a Graft message to its upstream neighbor if a group join 302 occurs for a group that the router has previously sent a prune. 303 Separate Graft messages must be sent to the appropriate upstream 304 neighbor for each source network that has been pruned. Since there 305 would be no way to tell if a Graft message sent upstream was lost or 306 the source simply quit sending traffic, it is necessary to 307 acknowledge each Graft message with a DVMRP Graft Ack message. If an 308 acknowledgment is not received within a Graft Time-out period, the 309 Graft message should be retransmitted using binary exponential back- 310 off between retransmissions. Duplicate Graft Ack messages should 311 simply be ignored. The purpose of the Graft Ack message is to simply 312 acknowledge the receipt of a Graft message. It does not imply that 313 any action was taken as a result of receiving the Graft message. 314 Therefore, all Graft messages received from a neighbor with whom a 315 two-way neighbor relationship has been formed should be acknowledged 316 whether or not they cause an action on the receiving router. 318 3. Detailed Protocol Operation 320 This section contains a detailed description of DVMRP. It covers 321 sending and receiving of DVMRP messages as well as the generation and 322 maintenance of IP Multicast forwarding cache entries. 324 3.1. Protocol Header 326 DVMRP packets are encapsulated in IP datagrams, with an IP protocol 327 number of 2 (IGMP) as specified in the Assigned Numbers RFC [Reyn94]. 328 All fields are transmitted in Network Byte Order. DVMRP packets use a 329 common protocol header that specifies the IGMP [Cain02] Packet Type 330 as hexadecimal 0x13 (DVMRP). DVMRP protocol packets should be sent 331 with the Precedence field in the IP header set to Internetwork 332 Control (hexadecimal 0xc0 for the Type of Service Octet) [Post81]. A 333 diagram of the common protocol header follows: 335 0 8 16 31 336 +---------+---------+--------------------+ 337 | Type | Code | Checksum | 338 |(0x13) | | | 339 +---------+---------+----------+---------+ 340 | Reserved | Minor | Major | 341 | | Version |Version | 342 +-------------------+----------+---------+ 344 Figure 1 - Common Protocol Header 346 A Major Version of 3 and a Minor Version of 0xFF should be used to 347 indicate compliance with this specification. The value of the Code 348 field determines the DVMRP packet type. Currently, there are codes 349 allocated for DVMRP protocol message types as well as protocol 350 analysis and troubleshooting packets. The protocol message Codes 351 are: 353 Code Packet Type Description 354 ---------------------------------------------------------------- 355 1 DVMRP Probe for neighbor discovery 356 2 DVMRP Report for route exchange 357 7 DVMRP Prune for pruning multicast delivery trees 358 8 DVMRP Graft for grafting multicast delivery trees 359 9 DVMRP Graft Ack for acknowledging graft messages 360 ---------------------------------------------------------------- 362 Table 1 - Standard Protocol Packet Types 364 There are additional codes used for protocol analysis and 365 troubleshooting. These codes are discussed in Appendix B. 367 The Checksum is the 16-bit one's complement of the one's complement 368 sum of the DVMRP message. The checksum MUST be calculated upon 369 transmission and MUST be validated on reception of a packet. The 370 checksum of the DVMRP message is calculated with the checksum field 371 set to zero. See [Brad88] for more information. 373 3.2. Probe Messages 375 When a DVMRP router is configured to run on an interface (physical or 376 tunnel), it multicasts DVMRP Probe packets to inform other DVMRP 377 routers that it is operational. Effectively, they serve three 378 purposes. 380 1. Probes provide a mechanism for DVMRP routers to locate each other. 381 DVMRP sends on each interface, a Probe Message containing the list 382 of the neighbors detected for that specific interface. If no 383 DVMRP neighbors are found, the network is considered to be a leaf 384 network. 386 2. Probes provide a way for DVMRP routers to determine the 387 capabilities of each other. This may be deduced from the major and 388 minor version numbers in the Probe packet or directly from the 389 capability flags. These flags were first introduced to allow 390 optional protocol features. This specification now mandates the 391 use of Generation Id's and pruning and, therefore, provides no 392 optional capabilities. Other capability flags were used for 393 tracing and troubleshooting and are no longer a part of the actual 394 protocol. 396 3. Probes provide a keep-alive function in order to quickly detect 397 neighbor loss. Probes sent on each multicast capable interface 398 configured for DVMRP SHOULD use an interval of 10 seconds. The 399 neighbor time-out interval SHOULD be set at 35 seconds. This 400 allows fairly early detection of a lost neighbor yet provides 401 tolerance for busy multicast routers. These values MUST be 402 coordinated between all DVMRP routers on a physical network 403 segment. 405 3.2.1. Router Capabilities 407 In the past, there have been many versions of DVMRP in use with a 408 wide range of capabilities. Practical considerations require a 409 current implementation to inter-operate with these older 410 implementations that don't formally specify their capabilities and 411 are not compliant with this specification. For instance, for major 412 versions less than 3, it can be assumed that the neighbor does not 413 support pruning. The formal capability flags were first introduced 414 in an well known implementation (Mrouted version 3.5) in an attempt 415 to take the guess work out which features are supported by a 416 neighbor. Many of these flags are no longer necessary since they are 417 now a required part of the protocol, however, special consideration 418 is necessary to not confuse older implementations that expect these 419 flags to be set. Appendix C was written to assist with these and 420 other backward compatibility issues. 422 Three of the flags were used for actual protocol operation. The 423 other two assigned flags were used for troubleshooting purposes which 424 should be documented in a separate specification. All of the bits 425 marked "U" in the Figure below are now unused. They may be defined in 426 the future and MUST be set to 0 on transmission and ignored on 427 reception. Bit position 0 is the LEAF bit which is a current research 428 topic. It MUST be set to 0 and ignored on reception. Bit positions 429 1, 2, and 3 MUST be set to 1 for backward compatibility. They were 430 used to specify the PRUNE, GENID, and MTRACE bits. The first two, 431 PRUNE and GENID, are now required features. The MTRACE bit must be 432 set so existing implementations will not assume this neighbor does 433 not support multicast trace-route [Fenn00]. However, since this bit 434 is now reserved and set to 1, newer implementations should not use 435 this bit in the Probe message to determine if multicast trace-route 436 is supported by a neighbor. Instead, the M bit should only be used in 437 a Neighbors2 message as described in Appendix B. The bit marked S 438 stands for SNMP capable. This bit is used by troubleshooting 439 applications and should only be tested in the Neighbors2 message. 441 The N bit (which stands for Netmask) is defined by this 442 specification. It is used to indicate the neighbor will accept 443 network masks appended to the Prune, Graft, and Graft Ack messages. 444 This bit only indicates that the neighbor understands the netmask. It 445 DOES NOT mean that Prune, Graft, and Graft Ack messages sent to this 446 neighbor must include a netmask. Refer to the sections on Prune, 447 Graft, and Graft Ack messages for more details. 449 Each time a Probe message is received from a neighbor, the 450 capabilities bits should be compared to the previous version for that 451 neighbor in order to detect changes in neighbor capabilities. 453 7 6 5 4 3 2 1 0 454 U U N S M G P L 455 +---+---+---+---+----+---+---+---+ 456 |0 |0 |X | 0 | 1 |1 |1 | 0 | 457 +---+---+---+---+----+---+---+---+ 459 Figure 2 - Probe Capability Flags 461 3.2.2. Generation ID 463 If a DVMRP router is restarted, it will not be aware of any previous 464 prunes that it had sent or received. In order for the neighbor to 465 detect that the router has restarted, a non-decreasing number is 466 placed in the periodic probe message called the generation ID. When 467 a change in the generation ID is detected, any prune information 468 received from the router is no longer valid and should be flushed. 469 If this prune state has caused prune information to be sent upstream, 470 a graft will need to be sent upstream just as though a new member has 471 joined below. Once data begins to be delivered downstream, if the 472 downstream router again decides to be pruned from the delivery tree, 473 a new prune can be sent upstream at that time. 475 In addition, the effects of a restart can be minimized if the router 476 can learn all of the routes known by its neighbors without having to 477 wait for an entire report interval to pass. When a router detects a 478 change in the generation ID of a neighbor, it should send a unicast 479 copy of its entire routing table to the neighbor. 481 In addition to restarting, a router may also miss prune information 482 while an interface has transitioned to a down state. Therefore, a 483 change in the generation ID is necessary when an interface 484 transitions to the up state. In order to prevent all prune state from 485 being flushed on a router when a single interface transitions, a 486 DVMRP router should keep separate generation ID numbers per 487 interface. 489 A time of day clock provides a good source for a non-decreasing 32 490 bit integer. 492 3.2.3. Neighbor Addresses 494 As a DVMRP router sees Probe messages from its DVMRP neighbors, it 495 records the neighbor addresses on each interface and places them in 496 the Probe message sent on the particular interface. This allows the 497 neighbor router to know that its probes have been received by the 498 sending router. 500 In order to minimize one-way neighbor relationships, a router MUST 501 delay sending poison route reports in response to routes advertised 502 by a neighbor until the neighbor includes the routers address in its 503 probe messages. On point-to-point interfaces and tunnel pseudo- 504 interfaces, this means that no packets should be forwarded onto these 505 interfaces until two-way neighbor relationships have formed. 507 Implementations written before this specification will not wait 508 before sending reports nor will they ignore reports sent. Therefore, 509 reports from these implementations SHOULD be accepted whether or not 510 a probe with the routers address has been received. 512 3.2.4. Neighbor Expiry 514 When a neighbor expires, the following steps should be taken: 516 1. All routes learned from this neighbor should be immediately placed 517 in hold-down. All downstream dependencies ON this neighbor should 518 be removed. 520 2. If this neighbor is considered to be the designated forwarder for 521 any of the routes it is advertising, a new designated forwarder 522 for each source network should be selected. 524 3. Any forwarding cache entries based on this upstream neighbor 525 should be flushed. 527 4. Any outstanding Grafts awaiting acknowledgments from this router 528 should be flushed. 530 5. All downstream dependencies received FROM this neighbor should be 531 removed. Forwarding cache entries should be checked to see if 532 this is the last downstream dependent neighbor on the interface. 533 If so, and this router isn't the designated forwarder (with local 534 group members present), the interface should be removed. 536 It is possible as an optimization to send a prune upstream if this 537 causes the last downstream interface to be removed. However, this 538 prune could be unnecessary if no more traffic is arriving. It is 539 also acceptable to simply wait for traffic to arrive before 540 sending the prune upstream. 542 3.2.5. Probe Packet Format 544 The Probe packet is variable in length depending on the number of 545 neighbor IP addresses included. The length of the IP packet can be 546 used to determine the number of neighbors in the Probe message. The 547 current Major Version is 3. 549 7 15 23 31 550 +---------+--------------+--------------------+ 551 | Type | Code | Checksum | 552 | (0x13) | (0x1) | | 553 +---------+--------------+----------+---------+ 554 | | | | | 555 |Reserved | Capabilities | Minor | Major | 556 +---------+--------------+----------+---------+ 557 | | 558 | Generation ID | 559 +---------------------------------------------+ 560 | | 561 | Neighbor IP Address 1 | 562 +---------------------------------------------+ 563 | | 564 | Neighbor IP Address 2 | 565 +---------------------------------------------+ 566 | | 567 | ... | 568 +---------------------------------------------+ 569 | | 570 | Neighbor IP Address N | 571 +---------------------------------------------+ 573 Figure 3 - DVMRP Probe Packet Format 575 Generation ID 576 This field contains a non-decreasing number used to detect a 577 change in neighbor state. 579 Neighbor IP Address N 580 This is a list of Neighbor IP addresses whom the sending router 581 has received Probe messages from. 583 3.2.6. IGMP Designated Querier Election 585 Since it is wasteful to have more than a single router sending IGMP 586 Host Membership Queries on a given physical network, a single router 587 on each physical network is elected as the Designated Querier. This 588 election was formerly a part of DVMRP. However, this is now 589 specified as a part of the IGMP version 2 protocol. See Appendix C 590 for details on backwards compatibility. 592 Even though only one router will act as the IGMP designated querier, 593 all DVMRP routers must use IGMP to learn local group memberships. 595 3.3. Multicast Forwarding 597 DVMRP can forward multicast packets by building the downstream 598 interface list for each packet as it arrives. However, to reduce per 599 packet processing time, the result of the first lookup MAY be cached 600 in a forwarding table. Then, as routes, downstream dependent 601 neighbors, or group membership change, the cache forwarding table 602 entries MUST be updated to reflect these changes. 604 3.3.1. Designated Forwarder 606 Initially, a DVMRP router should assume it is the designated 607 forwarder for all source networks on all downstream interfaces. As it 608 receives route reports, it can determine if other routers on multi- 609 access networks have better routes back to a particular source 610 network. A route is considered better if the adjusted received metric 611 is less than the metric that it will advertise for the source network 612 on the received interface or if the metrics are the same but the IP 613 address of the neighbor is lower. 615 If this neighbor becomes unreachable or starts advertising a worse 616 metric, then the router should become the designated forwarder for 617 this source network again on the downstream interface until it hears 618 from a better candidate. 620 If the upstream RPF interface changes, then the router should become 621 the designated forwarder on the previous upstream interface (which is 622 now a potential downstream interface) until it hears from a better 623 candidate. 625 3.3.2. Determining the upstream interface 627 When a multicast packet arrives, a DVMRP router will use the DVMRP 628 routing table to determine which interface leads back to the source. 629 If the packet did not arrive on that interface, it MUST be discarded 630 without further processing. Each multicast forwarding entry should 631 cache the upstream interface for a particular source host or source 632 network after looking this up in the DVMRP routing table. 634 3.3.3. Determining the downstream interface list 636 The downstream interface list is built by starting with the list of 637 non-leaf interfaces. The upstream interface MUST be removed from this 638 list. Then any interfaces on the list where all of the downstream 639 dependents have sent prunes upstream MUST be removed. Next, any 640 interfaces for which the router is the designated forwarder and local 641 group members are present MUST be added to the list. 643 3.4. Route Exchange 645 The routing information propagated by DVMRP is used for determining 646 the reverse path neighbor back to the source of the multicast 647 traffic. The interface used to reach this neighbor is called the 648 upstream interface. Tunnel pseudo-interfaces are considered to be 649 distinct from the physical interface on which the packet is actually 650 transmitted for the purpose of determining upstream and downstream 651 interfaces. 653 The routing information that is propagated by DVMRP contains a list 654 of source networks and an appropriate metric. The metric used is a 655 hop count which is incremented by the cost of the incoming interface 656 metric. Traditionally, physical interfaces use a metric of 1 while 657 the metric of a tunnel interface varies with the distance and 658 bandwidth in the path between the two tunnel endpoints. Users are 659 encouraged to configure tunnels with the same metric in each 660 direction to create symmetric routing and provide for easier problem 661 determination although the protocol does not strictly enforce this. 663 3.4.1. Source Network Aggregation 664 Implementations may wish to provide a mechanism to aggregate source 665 networks to reduce the size of the routing table. All implementations 666 should be able to accept reports for aggregated source networks in 667 accordance with Classless Inter-Domain Routing (CIDR) as described in 668 [Rekh93] and [Full93]. 670 There are two places where aggregation is particularly useful. 672 1. At organizational boundaries to limit the number of source 673 networks advertised out of the organization. 675 2. Within an organization to summarize non-local routing information 676 by using a default (0/0) route. 678 If an implementation wishes to support source aggregation, it MUST 679 transmit Prune and Graft messages according to the following rules: 681 A. If a Prune is received on a downstream interface for which the 682 source network advertised to that neighbor is an aggregate, then 683 if a prune is sent upstream, it should only be sent for the 684 contributing route based on the source address in the received 685 prune. 687 If additional data is received for sources within the range of the 688 aggregate, then this SHOULD trigger additional prunes to be sent 689 upstream for these sources. 691 There may be active forwarding cache entries for other 692 contributing routes to the aggregate. Prunes should not be sent 693 upstream to the contributing routes that have no forwarding state. 695 B. If a Graft is received on a downstream interface for which the 696 source network advertised to that neighbor is an aggregate 697 generated by the receiving router, then Graft messages MUST be 698 sent upstream (if necessary) for each route that contributed to 699 the aggregate that had been previously pruned. 701 3.4.2. Route Packing and Ordering 703 Since DVMRP Route Reports may need to refresh several thousand routes 704 each report interval, routers MUST attempt to spread the routes 705 reported across the whole route update interval. This reduces the 706 chance of synchronized route reports causing routers to become 707 overwhelmed for a few seconds each report interval. Since the route 708 report interval is 60 seconds, it is suggested that the total number 709 routes being updated be split across multiple Route Reports sent at 710 regular intervals. There was an earlier requirement that Route 711 Reports MUST contain source network/mask pairs sorted first by 712 increasing network mask and then by increasing source network. This 713 restriction has been lifted. Implementations conforming to this 714 specification MUST be able to receive Route Reports containing any 715 mixture of network masks and source networks. 717 In order to pack more source networks into a route report, source 718 networks are often represented by less than 4 octets. The number of 719 non-zero bytes in the mask value is used to determine the number of 720 octets used to represent each source network within that particular 721 mask value. For instance if the mask value of 255.255.0.0 is being 722 reported, the source networks would only contain 2 octets each. DVMRP 723 assumes that source networks will never be aggregated into networks 724 whose prefix length is less than 8. Therefore, it does not carry the 725 first octet of the mask in the Route Report since, given this 726 assumption, the first octet will always be 0xFF. This means that the 727 netmask value will always be represented in 3 octets. This method of 728 specifying source network masks is compatible with techniques 729 described in [Rekh93] and [Full93] to group traditional Class C 730 networks into super-nets and to allow different subnets of the same 731 Class A network to be discontinuous. It does not, however, allow 732 grouping class A networks into super-nets since the first octet of 733 the netmask is always assumed to be 255. 735 In this notation, the default route is represented as the least three 736 significant octets of the netmask [00 00 00], followed by one octet 737 for the network number [00]. This special case MUST be interpreted 738 as 0.0.0.0/0.0.0.0 and NOT 0.0.0.0/255.0.0.0. 740 3.4.3. Route Metrics 742 For each source network reported, a route metric is associated with 743 the route being reported. The metric is the sum of the interface 744 metrics between the router originating the report and the source 745 network. For the purposes of DVMRP, the Infinity metric is defined to 746 be 32. This limits the breadth across the whole DVMRP network and is 747 necessary to place an upper bound on the convergence time of the 748 protocol. 750 As seen in the packet format below, Route Reports do not contain a 751 count of the number of routes reported for each netmask. Instead, a 752 "Last" bit is defined as the high order bit of the octet following 753 the network address. This bit is set to signify when the last route 754 is being reported for a particular mask value. When the "Last" bit 755 is set and the end of the message has not been reached, the next 756 value will be a new netmask to be applied to the subsequent list of 757 routes. 759 3.4.4. Route Dependencies 761 In order for pruning to work correctly, each DVMRP router needs to 762 know which downstream routers depend on it for receiving datagrams 763 from particular source networks. Initially, when a new datagram 764 arrives from a particular source/group pair, it is broadcasted to all 765 downstream interfaces that have DVMRP neighbors who have indicated a 766 dependency on the receiving DVMRP router for that particular source. 767 A downstream interface can only be removed when the router has 768 received Prune messages from each of the dependent routers on that 769 interface. Each downstream router uses Poison Reverse to indicate 770 for which source networks it is dependent upon the upstream router. 771 The downstream router indicates this by echoing back the source 772 networks it expects to receive from the upstream router with infinity 773 added to the advertised metric. This means that the legal values for 774 the metric now become between 1 and (2 x Infinity - 1) or 1 and 63. 775 Values between 1 and 31 indicate reachable source networks. The value 776 Infinity (32) indicates the source network is not reachable. Values 777 between 33 and 63 indicate that the downstream router originating the 778 Report is depending upon the upstream router to provide multicast 779 datagrams from the corresponding source network. 781 3.4.5. Sending Route Reports 783 All of the active routes MUST be advertised over all interfaces with 784 neighbors present each Route Report Interval. In addition, flash 785 updates MAY be sent as needed but flash updates MUST NOT happen more 786 often than the Minimum Flash Update Interval (5 seconds). Flash 787 updates reduce the chances of routing loops and black holes occurring 788 when source networks become unreachable through a particular path. 789 Flash updates need only contain the source networks that have 790 changed. 792 When a router sees its own address in a neighbor probe packet for the 793 first time, it should send a unicast copy of its entire routing table 794 to the neighbor to reduce start-up time. 796 Reports should not be sent to a neighbor until a router has seen its 797 own address in the neighbors Probe router list. See Appendix C for 798 exceptions. 800 3.4.6. Receiving Route Reports 802 After receiving a route report, a check should be made to verify it 803 is from a known neighbor. Two-way neighbor relationships are 804 essential for proper DVMRP operation. Therefore, route reports from 805 unknown neighbors MUST be discarded. 807 In the following discussion, "Metric" refers to the metric of the 808 route as received in the route report. "Adjusted Metric" refers to 809 the metric of the route after the incoming interface metric has been 810 added. 812 If the metric received is less than infinity but the Adjusted Metric 813 is greater than or equal to infinity, the Adjusted Metric should be 814 set to infinity. 816 If the metric is greater than or equal to infinity, then no 817 adjustment of the metric should be made. 819 Each route in the report is then parsed and processed according to 820 the following rules: 822 A. If the route is new and the Adjusted Metric is less than infinity, 823 the route should be added. 825 B. If the route already exists, several checks must be performed. 827 1. Received Metric < infinity 829 If the neighbor was considered a downstream dependent neighbor, 830 the dependency is canceled. 832 In the following cases, the designated forwarder on one of the 833 downstream interfaces should be updated: 835 - If the Metric received would cause the router to advertise a 836 better metric on a downstream interface than the existing 837 designated forwarder for the source network on that 838 interface (or advertised metric would be the same but the 839 router's IP address is lower than the existing designated 840 forwarder on that interface). Then the receiving router 841 becomes the new designated forwarder for that source network 842 on that interface. If this router had sent a prune upstream 843 that is still active, it will need to send a graft. 845 - If the metric being advertised by the current designated 846 forwarder is worse than the receiving routers metric that it 847 would advertise on the receiving interface (from learning 848 the same route from a neighbor on another interface) or the 849 metric is the same but the receiving router has a lower IP 850 address, then the receiving router becomes the new 851 designated forwarder on that interface. This may trigger a 852 graft to be sent upstream. 854 - If the metric received for the source network is better than 855 the metric of the existing designated forwarder, save the 856 new designated forwarder and the metric it is advertising. 857 It is necessary to maintain knowledge of the current 858 designated forwarder for each source network in case the 859 time-out value for this neighbor is reached. If the time-out 860 is reached, then the designated forwarder responsibility for 861 the source network should be assumed. 863 A route is considered better when either the received Metric is 864 lower than the existing metric or the received Metric is the 865 same but the advertising router's IP address is lower. 867 a. Adjusted Metric > existing metric 869 If the Adjusted Metric is greater than the existing metric, 870 then check to see if the same neighbor is reporting the 871 route. If so, update the route metric and schedule a flash 872 update containing the route. Otherwise, skip to the next 873 route in the report. 875 b. Adjusted Metric < existing metric 877 Update the metric for the route and if the neighbor 878 reporting the route is different, update the upstream 879 neighbor in the routing table. Schedule a flash update 880 containing the route to downstream neighbors and a flash 881 poison update containing the route should be sent upstream 882 indicating a change in downstream dependency (even if its on 883 the same upstream interface). 885 c. Adjusted metric = existing metric 887 If the neighbor reporting the route is the same as the 888 existing upstream neighbor, then simply refresh the route. 890 If the neighbor is the same and the route is in hold-down, 891 it is permissible to prematurely take the route out of hold- 892 down and begin advertising it with a non-infinity metric. 893 If the route is taken out of hold-down, a flash update 894 containing the route should be scheduled on all DVMRP 895 interfaces except the one over which it was received. 897 If the neighbor reporting the route has a lower IP address 898 than the existing upstream neighbor, then switch to this 899 neighbor as the best route. Schedule a flash update 900 containing the route to downstream neighbors and a flash 901 poison update containing the route should be sent upstream 902 indicating a change in downstream dependency (even if its on 903 the same upstream interface). 905 2. Received Metric = infinity 906 If the neighbor was considered to be the designated 907 forwarder, the receiving router should now become the 908 designated forwarder for the source network on this 909 interface. 911 a. Next hop = existing next hop 913 If the existing metric was less than infinity, the route is 914 now unreachable. Delete the route and schedule a flash 915 update containing the route to all interfaces for which you 916 are the designated forwarder or have downstream dependents. 918 b. Next hop != existing next hop 920 The route can be ignored since the existing next hop has a 921 metric better than or equal to this next hop. 923 If the neighbor was considered a downstream dependent 924 neighbor, this should be canceled. 926 3. infinity < Received Metric < 2 x infinity 928 The neighbor considers the receiving router to be upstream for 929 the route and is indicating it is dependent on the receiving 930 router. 932 If the neighbor was considered to be the designated forwarder, 933 the receiving router should now become the designated forwarder 934 for the source network on this interface. 936 a. Neighbor on downstream interface 938 If the sending neighbor is considered to be on a downstream 939 interface for that route then the neighbor is to be 940 registered as a downstream dependent router for that route. 942 If this is the first time the neighbor has indicated 943 downstream dependence for this source and one or more prunes 944 have been sent upstream containing this source network, then 945 Graft messages MUST be sent upstream in the direction of the 946 source network for each group with existing prune state. 948 b. Neighbor on upstream interface 950 If the receiving router thinks the neighbor is on the 951 upstream interface, then the route should be treated as if 952 an infinity metric was received (See Received Metric = 953 infinity). 955 4. 2 x infinity <= Received Metric 957 If the Received Metric is greater than or equal to 2 x 958 infinity, the Metric is illegal and the route should be 959 ignored. 961 3.4.7. Route Expiration 963 A route expires if it has not been refreshed within the Route 964 Expiration time. This should be set to 2 x Route Report Interval + 20 965 (or 140) seconds. Due to flash updates, routes will typically not 966 expire but instead be removed in response to receiving an infinity 967 metric for the route. However, since not all existing 968 implementations implement flash updates, route expiration is 969 necessary. 971 3.4.8. Route Hold-down 973 When a route is deleted (because it expires, the neighbor it was 974 learned from goes away, or an infinity metric is received for the 975 route) a router may be able to reach the source network described by 976 the route through an alternate gateway. However, in the presence of 977 complex topologies, often, the alternate gateway may only be echoing 978 back the same route learned via a different path. If this occurs, the 979 route will continue to be propagated long after it is no longer 980 valid. 982 In order to prevent this, it is common in distance vector protocols 983 to continue to advertise a route that has been deleted with a metric 984 of infinity for one or more report intervals. This is called Hold- 985 down. A route MUST only be advertised with an infinity metric while 986 it is in hold-down. The hold-down period is 2 Report Intervals. 988 When a route goes into hold-down, all forwarding cache entries based 989 on the route should be flushed. 991 During the hold-down period, the route may be learned via a different 992 gateway or the same gateway with a different metric. The router MAY 993 use this new route for delivering to local group members. Also, 994 installing a new route during the hold-down period allows the route 995 to be advertised with a non-infinity metric more quickly once the 996 hold-down period is over. 998 In order to minimize outages caused by flapping routes, it is 999 permissible to prematurely take a route out of hold-down ONLY if the 1000 route is re-learned from the SAME router with the SAME metric. 1002 Route hold-down is not effective if only some routers implement it. 1003 Therefore, it is now a REQUIRED part of the protocol. 1005 3.4.9. Graceful Shutdown 1007 During a graceful shutdown, an implementation MAY want to inform 1008 neighbor routers that it is terminating. Routes that have been 1009 advertised with a metric less than infinity should now be advertised 1010 with a metric equal to infinity. This will allow neighbor routers to 1011 switch more quickly to an alternate path for a source network if one 1012 exists. 1014 Routes that have been advertised with a metric between infinity and 2 1015 x infinity (indicating downstream neighbor dependence) should now be 1016 advertised with a metric equal to infinity (canceling the downstream 1017 dependence). 1019 3.4.10. Route Report Packet Format 1021 The format of a sample Route Report Packet is shown in Figure 4 1022 below. The packet shown is an example of how the source networks are 1023 packed into a Report. The number of octets in each Source Network 1024 will vary depending on the mask value. The values below are only an 1025 example for clarity and are not intended to represent the format of 1026 every Route Report. 1028 7 15 23 31 1029 +-----------+------------+-------------------------+ 1030 | Type | Code | Checksum | 1031 | (0x13) | (0x2) | | 1032 +-----------+------------+------------+------------+ 1033 | Reserved | Minor | Major | 1034 | | Version | Version | 1035 +-----------+------------+------------+------------+ 1036 | Mask1 | Mask1 | Mask1 | Src | 1037 | Octet2 | Octet3 | Octet4 | Net11 | 1038 +-----------+------------+------------+------------+ 1039 | SrcNet11(cont.)... | Metric11 | Src | 1040 | | | Net12 | 1041 +------------------------+------------+------------+ 1042 | SrcNet12(cont.)... | Metric12 | Mask2 | 1043 | | | Octet2 | 1044 +-----------+------------+------------+------------+ 1045 | Mask2 | Mask2 | SrcNet21 | 1046 | Octet3 | Octet4 | | 1047 +-----------+------------+------------+------------+ 1048 | SrcNet21(cont.)... | Metric21 | Mask3 | 1049 | | | Octet2 | 1050 +-----------+------------+------------+------------+ 1051 | Mask3 | Mask3 | ... | 1052 | Octet3 | Octet4 | | 1053 +-----------+------------+-------------------------+ 1055 Figure 4 - Example Route Report Packet Format 1057 3.5. Pruning 1059 DVMRP is described as a broadcast and prune multicast routing 1060 protocol since datagrams are initially sent out all dependent 1061 downstream interfaces forming a tree rooted at the source of the 1062 data. As the routers at the leaves of the tree begin to receive 1063 unwanted multicast traffic, they send prune messages upstream toward 1064 the source. This results in the multicast tree for a given source 1065 network and a given set of receivers. 1067 3.5.1. Leaf Networks 1069 Detection of leaf networks is very important to the pruning process. 1070 Routers at the end of a source specific multicast delivery tree must 1071 detect that there are no further downstream dependent routers. This 1072 detection mechanism is covered above in section 3.2 titled Probe 1073 Messages. If there are no group members present for a particular 1074 multicast datagram received, the leaf routers will start the pruning 1075 process by removing their downstream interfaces and sending a prune 1076 to the upstream router for that source. 1078 3.5.2. Source Networks 1080 By default, prunes are meant to be applied to a group and source 1081 network. However, it is possible to include a Netmask in the Prune 1082 message to alter this behavior. If no Netmask is included, a prune 1083 sent upstream triggered by traffic received from a particular source 1084 applies to all sources on that network. If a Netmask is included, it 1085 MUST first be validated. If the Netmask is a host mask, only that 1086 source address should be pruned. Otherwise, the Netmask MUST match 1087 the mask sent to the downstream router for that source. If it does 1088 not match the mask that the upstream router expected, the upstream 1089 router MUST ignore the prune and should log an error. When a 1090 aggregate source network is advertised downstream, the Netmask in the 1091 prune will match the mask of the aggregate route that was advertised. 1093 If the Prune message only contains the host address of the source 1094 (and not the corresponding Netmask), the source network can be 1095 determined easily by a best-match lookup using the routing table 1096 distributed as a part of DVMRP. 1098 3.5.3. Receiving a Prune 1100 When a prune is received, the following steps should be taken: 1102 1. If the neighbor is unknown, discard the received prune. 1104 2. Ensure the prune message contains at least the correct amount of 1105 data. 1107 3. Copy the source address, group address, and prune time-out value. 1108 If it is available in the packet, copy the Netmask value. 1109 Determine route to which prune applies. 1111 4. If there is no active source information for the (source network, 1112 group) pair, then ignore the prune. 1114 5. Verify that the prune was received from a dependent neighbor for 1115 the source network. If not, discard the prune. 1117 6. Determine if a prune is currently active from the same dependent 1118 neighbor for this (source network, group) pair. 1120 7. If so, reset the timer to the new time-out value. Otherwise, 1121 create state for the new prune and set a timer for the prune 1122 lifetime. 1124 8. Determine if all dependent downstream routers on the interface 1125 from which the prune was received have now sent prunes. 1127 9. If so, then determine if there are group members active on the 1128 interface and if this router is the designated forwarder for the 1129 network. 1131 10. If not, then remove the interface from all forwarding cache 1132 entries for this group instantiated using the route to which the 1133 prune applies. 1135 3.5.4. Sending a Prune 1137 When a forwarding cache is being used, there is a trade-off that should 1138 be considered when deciding when Prune messages should be sent upstream. 1139 In all cases, when a data packet arrives and the downstream interface 1140 list is empty, a prune is sent upstream. However, when a forwarding 1141 cache entry transitions to an empty downstream interface list it is 1142 possible as an optimization to send a prune at this time as well. This 1143 prune will possibly stop unwanted traffic sooner at the expense of 1144 sending extra prune traffic for sources that are no longer sending. 1145 When sending a prune upstream, the following steps should be taken: 1147 1. Decide if upstream neighbor is capable of receiving prunes. 1149 2. If not, then proceed no further. 1151 3. Stop any pending Grafts awaiting acknowledgments. 1153 4. Determine the prune lifetime. This value should be the minimum of 1154 the default prune lifetime (randomized to prevent synchronization) 1155 and the remaining prune lifetimes of the downstream neighbors. 1157 5. Form and transmit the packet to the upstream neighbor for the 1158 source. 1160 3.5.5. Retransmitting a Prune 1162 By increasing the prune lifetime to ~2 hours, the effect of a lost 1163 prune message becomes more apparent. Therefore, an implementation 1164 SHOULD retransmit prunes messages using binary exponential back-off 1165 during the lifetime of the prune if traffic is still arriving on the 1166 upstream interface. 1168 One way to implement this would be to send a prune, install a 1169 negative cache entry for 3 seconds while waiting for the prune to 1170 take effect. Then remove the negative cache entry. If traffic 1171 continues to arrive, a new forwarding cache request will be 1172 generated. The prune can be resent with the remaining prune lifetime 1173 and a negative cache entry can be installed for 6 seconds. After 1174 this, the negative cache entry is removed. This procedure is repeated 1175 while each time doubling the length of time the negative cache entry 1176 is installed. 1178 In addition to using binary exponential back-off, the interval 1179 between subsequent retransmissions should also be randomized to 1180 prevent synchronization. 1182 On multi-access networks, even if a prune is received by the upstream 1183 router, data may still be received due to other receivers (i.e. group 1184 members or other downstream dependent routers) on the network. 1186 3.5.6. Prune Packet Format 1188 A Prune Packet contains three required fields: the source host IP 1189 address, the destination group IP address, and the Prune Lifetime in 1190 seconds. An optional source network mask may also be appended to the 1191 Prune message. This mask applied to the Source Host Address will 1192 indicate the route that the prune applies to. A Source Network Mask 1193 field should only be sent in a Prune message to a neighbor if that 1194 neighbor has advertised the ability to process it by setting the 1195 Netmask capabilities bit. The length of the Prune message will 1196 indicate if the Source Network Mask has been included or not. 1198 The Prune Lifetime is a derived value calculated as the minimum of 1199 the default prune lifetime (2 hours) and the remaining lifetimes of 1200 any downstream prunes received for this source network and group. A 1201 router with no downstream dependent neighbors would use the the 1202 default prune lifetime (randomized to prevent synchronization). 1204 7 15 23 31 1205 +-----------+------------+-------------------------+ 1206 | Type | Code | Checksum | 1207 | (0x13) | (0x7) | | 1208 +-----------+------------+------------+------------+ 1209 | Reserved | Minor | Major | 1210 +------------------------+------------+------------+ 1211 | Source Host Address | 1212 +--------------------------------------------------+ 1213 | Group Address | 1214 +--------------------------------------------------+ 1215 | Prune Lifetime | 1216 +--------------------------------------------------+ 1217 | Source Network Mask | 1218 +--------------------------------------------------+ 1220 Figure 5 - Prune Packet Format 1222 Source Host Address 1223 The source host IP address of the datagram that triggered the 1224 prune. 1226 Group Address 1227 The destination group IP address of the datagram that triggered 1228 the prune. 1230 Prune Lifetime 1231 The number of seconds for which the upstream neighbor should keep 1232 this prune active. 1234 Source Network Mask 1235 The (optional) netmask of the route this prune applies to. 1237 3.6. Grafting 1239 Once a multicast delivery tree has been pruned back, DVMRP Graft 1240 messages are necessary to join new receivers onto the multicast tree. 1241 Graft messages are sent upstream hop-by-hop from the new receiver's 1242 first-hop router until a point on the multicast tree is reached. 1243 Since there is no way to tell whether a graft message was lost or the 1244 source stopped sending, each Graft message is acknowledged hop by 1245 hop. This ensures that the Graft message is not lost somewhere along 1246 the path between the receiver's first-hop router and the closest 1247 point on the multicast delivery tree. 1249 One or more Graft messages should be sent under the following 1250 conditions: 1252 1. A new local member joins a group that has been pruned upstream and 1253 this router is the designated forwarder for the source. 1255 2. A new dependent downstream router appears on a pruned branch. 1257 3. A dependent downstream router on a pruned branch restarts (new 1258 Generation ID). 1260 4. A Graft Retransmission Timer expires before a Graft-Ack is 1261 received. 1263 3.6.1. Sending a Graft 1265 Recall that by default, Prunes are source network specific and are 1266 sent up different trees for each source network. Grafts are sent in 1267 response to various conditions which are not necessarily source 1268 specific. Therefore, it may be necessary to send separate Graft 1269 messages to the appropriate upstream routers to counteract each 1270 previous source network specific prune that was sent. 1272 As mentioned above, a Graft message sent to the upstream DVMRP router 1273 should be acknowledged hop by hop guaranteeing end-to-end delivery. 1274 In order to send a Graft message, the following steps should be 1275 taken: 1277 1. Verify a prune exists for the source network and group. 1279 2. Verify that the upstream router is capable of receiving prunes 1280 (and therefore grafts). 1282 3. Add the graft to the retransmission timer list awaiting an 1283 acknowledgment. 1285 4. Formulate and transmit the Graft packet. 1287 If a Graft Acknowledgment is not received within the Graft 1288 Retransmission Time-out period, the Graft should be resent to the 1289 upstream router. The initial retransmission period is 5 seconds. A 1290 binary exponential back-off policy is used on subsequent 1291 retransmissions. 1293 3.6.2. Receiving a Graft 1295 1. If the neighbor is unknown, discard the received graft. 1297 2. Ensure the graft message contains at least the correct amount of 1298 data. 1300 3. Send back a Graft Ack to the sender. 1302 4. If the sender was a downstream dependent neighbor from which a 1303 prune had previously been received, then remove the prune state 1304 for this neighbor. If necessary, any forwarding cache entries 1305 based on this (source, group) pair should be updated to include 1306 this downstream interface. 1308 5. If a prune had been sent upstream, this may trigger a graft to 1309 now be sent to the upstream router. 1311 3.6.3. Graft Packet Format 1313 The format of a Graft packet is show below: 1315 7 15 23 31 1316 +-----------+------------+-------------------------+ 1317 | Type | Code | Checksum | 1318 | (0x13) | (0x8) | | 1319 +-----------+------------+------------+------------+ 1320 | Reserved | Minor | Major | 1321 +------------------------+------------+------------+ 1322 | Source Host Address | 1323 +--------------------------------------------------+ 1324 | Group Address | 1325 +--------------------------------------------------+ 1326 | Source Network Mask | 1327 +--------------------------------------------------+ 1329 Figure 6 - Graft Packet Format 1331 Source Host Address 1332 The source host IP address indicating which source host or source 1333 network to Graft. 1335 Group Address 1336 The destination group IP address to be grafted. 1338 Source Network Mask 1339 The (optional) netmask of the route this graft applies to. 1341 3.6.4. Sending a Graft Acknowledgment 1343 A Graft Acknowledgment packet is sent to a downstream neighbor in 1344 response to receiving a Graft message. All Graft messages MUST be 1345 acknowledged. This is true even if no other action is taken in 1346 response to receiving the Graft to prevent the source from 1347 continually re-transmitting the Graft message. The Graft 1348 Acknowledgment packet is identical to the Graft packet except that 1349 the DVMRP code in the common header is set to Graft Ack. This allows 1350 the receiver of the Graft Ack message to correctly identify which 1351 Graft was acknowledged and stop the appropriate retransmission timer. 1353 3.6.5. Receiving a Graft Acknowledgment 1355 When a Graft Acknowledgment is received, ensure the message contains 1356 at least the correct amount of data. The (source address, group) 1357 pair in the packet can be used to determine if a Graft was sent to 1358 this particular upstream router. If no Graft was sent, the Graft Ack 1359 can simply be ignored. If a Graft was sent, and the acknowledgment 1360 has come from the correct upstream router, then it has been 1361 successfully received and the retransmission timer for the Graft can 1362 be stopped. 1364 3.6.6. Graft Acknowledgment Packet Format 1366 The format of a Graft Ack packet (which is identical to that of a 1367 Graft packet) is show below: 1369 7 15 23 31 1370 +-----------+------------+-------------------------+ 1371 | Type | Code | Checksum | 1372 | (0x13) | (0x9) | | 1373 +-----------+------------+------------+------------+ 1374 | Reserved | Minor | Major | 1375 +------------------------+------------+------------+ 1376 | Source Host Address | 1377 +--------------------------------------------------+ 1378 | Group Address | 1379 +--------------------------------------------------+ 1380 | Source Network Mask | 1381 +--------------------------------------------------+ 1383 Figure 7 - Graft Ack Packet Format 1385 Source Host Address 1386 The source host IP address that was received in the Graft message. 1388 Group Address 1389 The destination group IP address that was received in the Graft 1390 message. 1392 Source Network Mask 1393 The (optional) netmask of the route this Graft Ack applies to. 1395 3.7. Interfaces 1397 Interfaces running DVMRP will either be multicast capable physical 1398 interfaces or encapsulated tunnel pseudo-interfaces. Physical 1399 interfaces may either be multi-access networks or point-to-point 1400 networks. Tunnel interfaces are used when there are non-multicast 1401 capable routers between DVMRP neighbors. Protocol messages and 1402 multicast data traffic are sent between tunnel endpoints using a 1403 standard encapsulation method [Perk96,Han94a,Han94b]. The unicast IP 1404 addresses of the tunnel endpoints are used as the source and 1405 destination IP addresses in the outer IP header. The inner IP header 1406 remains unchanged from the original packet. 1408 Protocol messages on point-to-point links should always use a 1409 destination IP address of All-DVMRP-Routers for ALL message types. 1410 While Prune, Graft, and Graft-Ack messages are only intended for a 1411 single recipient, the use of a multicast destination address is 1412 necessary for un-numbered links and encapsulated interfaces. 1414 When multiple addresses are configured on a single interface, it is 1415 necessary that all routers on the interface know about the same set 1416 of network addresses. In this way, each router will make the same 1417 choice for the designated forwarder for each source. In addition, a 1418 router configured with multiple addresses on an interface should 1419 consistently use the same address when sending DVMRP control 1420 messages. 1422 The maximum packet length of any DVMRP message should be the maximum 1423 packet size required to be forwarded without fragmenting. The use of 1424 Path MTU Discovery [Mogu90] is encouraged to determine this size. In 1425 the absence of Path MTU, the Requirements for Internet Hosts [Brad89] 1426 specifies this number as 576 octets. Be sure to consider the size of 1427 the encapsulated IP header as well when calculating the maximum size 1428 of a DVMRP protocol message. 1430 3.7.1. Interface transitions 1432 When an interface transitions to the up state, the generation ID of 1433 that interface should be updated so that DVMRP neighbors know to 1434 resend prune information. 1436 When an interface transitions to the down state, all neighbors on 1437 that interface should be expired. All actions associated with an 1438 expired neighbor should be taken as specified in the Neighbor Expiry 1439 section. 1441 4. IANA Considerations 1443 The Internet Assigned Numbers Authority (IANA) is the central 1444 coordinator for the assignment of unique parameter values for 1445 Internet protocols. DVMRP uses IGMP [Cain02] IP protocol messages to 1446 communicate between routers. The IGMP Type field is hexadecimal 0x13. 1448 On IP multicast capable networks, DVMRP uses the All-DVMRP-Routers 1449 local multicast group. This group address is 224.0.0.4. 1451 5. Network Management Considerations 1452 DVMRP provides several methods for network management monitoring and 1453 troubleshooting. Appendix B describes a request/response mechanism to 1454 directly query DVMRP neighbor information. In addition, a Management 1455 Information Base for DVMRP is defined in [Thal97]. 1457 A Management Information Base for the multicast forwarding cache is 1458 defined in [McCl00]. 1460 Also, a protocol independent multicast trace-route facility is 1461 defined in [Fenn00]. 1463 6. Security Considerations 1465 Security for DVMRP follows the general security architecture provided 1466 for the Internet Protocol [Ken98a]. The IPsec authentication header 1467 [Ken98b] MAY be used to provide data integrity protection and 1468 groupwise data origin authentication of DVMRP protocol messages. 1470 Currently, the IPsec anti-replay option does not handle the case of a 1471 Security Association identified by a multicast destination address. 1472 Thus, the anti-replay option currently must be disabled on these 1473 Security Associations. The anti-replay option SHOULD be enabled on 1474 all security associations having a unicast destination address. 1476 There are only two DVMRP protocol message types sent to a multicast 1477 destination address. The effects of replaying these messages are 1478 outlined below: 1480 DVMRP Probes 1482 The Probe message contains two important state mechanisms. The 1483 first is the Generation ID. This is a non-decreasing number that 1484 allows the neighbors to detect if the router has been restarted. 1485 If an old Probe message is replayed, the Generation ID will either 1486 be the same or smaller than the current Generation ID. If it is 1487 smaller, then the replayed Probe will be ignored. If it is the 1488 same, then the message will continue to be processed. 1490 The second state mechanism is the list of neighbors a router has 1491 learned. If a neighbor no longer appears in this list, then any 1492 existing prune information learned from this neighbor will be 1493 removed. This may cause multicast data to once again be flooded 1494 onto networks where it is not needed. 1496 In addition, downstream dependent neighbors are based on the 1497 neighbor list in the Probe message. If a neighbor no longer 1498 appears in this list, it will be removed from the downstream 1499 dependent list for each prefix that it expects to receive data 1500 from. Therefore, it is possible to stop data from being forwarded 1501 downstream by replaying an older Probe message that doesn't 1502 contain the neighbor address. 1504 However, because the Probe messages are periodic, the replayed 1505 message would have to be continuously sent after each periodic 1506 Probe message that contains a valid neighbor list. 1508 DVMRP Reports 1510 DVMRP Report messages are sent with both unicast and multicast 1511 destination addresses. Report messages that have multicast 1512 destinations are periodic Reports containing prefixes learned by 1513 the router. If these Reports were to be replayed at a later time, 1514 they could disrupt a routers ability to correctly determine the 1515 upstream interface of a source and therefore, stop forwarding of 1516 multicast data. 1518 Periodic Route Reports would continue containing correct 1519 information which could result in route flapping or holddown 1520 preventing multicast data from being forwarded for sources falling 1521 within the prefix ranges in the replayed Reports. 1523 DVMRP Prune, Graft, and Graft-Ack messages use unicast destination 1524 addresses. Security Associations between neighbors sending and 1525 receiving these protocol message types can make full use of the 1526 anti-replay protection provided by the IP security protocols. 1528 7. References 1530 [Brad88] Braden, R., Borman, D., Partridge, C., "Computing the 1531 Internet Checksum", RFC 1071, September 1988. 1533 [Brad89] Braden, R., "Requirements for Internet Hosts -- 1534 Communication Layers", RFC 1122, October 1989. 1536 [Cain02] Cain, B., Deering, S., Kouvelas, I., Fenner, W., 1537 Thyagarajan, A., "Internet Group Management Protocol, 1538 Version 3", RFC 3376, October 2002. 1540 [Deer89] Deering, S., "Host Extensions for IP Multicasting", RFC 1541 1112, August 1989. 1543 [Deer90] Deering, S., Cheriton, D., "Multicast Routing in Datagram 1544 Internetworks and Extended LANs", ACM Transactions on 1545 Computer Systems, Vol. 8, No. 2, May 1990, pp. 85-110. 1547 [Deer91] Deering, S., "Multicast Routing in a Datagram 1548 Internetwork", PhD thesis, Electric Engineering Dept., 1549 Stanford University, December 1991. 1551 [Fenn00] Fenner, W., Casner, S., "A "traceroute" facility for IP 1552 Multicast", Work In Progress, July 2000. 1554 [Full93] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 1555 Inter-Domain Routing (CIDR): an Address Assignment and 1556 Aggregation Strategy", RFC 1519, September 1993. 1558 [Han94a] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic 1559 Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and 1560 cisco Systems, October 1994. 1562 [Han94b] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1563 Routing Encapsulation over IPv4 networks", RFC 1702, 1564 NetSmiths, Ltd., cisco Systems, October 1994. 1566 [Ken98a] Kent, S., Atkinson, R. "Security Architecture for the 1567 Internet Protocol", RFC 2401, November 1998. 1569 [Ken98b] Kent, S., Atkinson, R., "IP Authentication Header", RFC 1570 2402, November 1998. 1572 [McCl00] McCloghrie, K., Farinacci, D., Thaler, D., "IPv4 Multicast 1573 Routing MIB", RFC 2932, October 2000. 1575 [Mogu90] Mogul, J., Deering, S., "Path MTU Discovery", RFC 1191, 1576 November 1990. 1578 [Perk96] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1579 October 1996. 1581 [Perl92] Perlman, R., "Interconnections: Bridges and Routers", 1582 Addison-Wesley, May 1992, pp. 205-211. 1584 [Post81] Postel, J., "Internet Protocol", RFC 791, September, 1981. 1586 [Rekh93] Rekhter, Y., and T. Li, "An Architecture for IP Address 1587 Allocation with CIDR", RFC 1518, September 1993. 1589 [Reyn94] Reynolds, J., Postel, J., "Assigned Numbers", STD 0002, 1590 October 1994. 1592 [Thal97] Thaler, D., "Distance-Vector Multicast Routing Protocol 1593 MIB", Work In Progress, April 1997. 1595 [Wait88] Waitzman, D., Partridge, C., Deering, S., "Distance Vector 1596 Multicast Routing Protocol", RFC 1075, November 1988. 1598 8. Author's Address 1600 Thomas Pusateri 1601 Juniper Networks, Inc. 1602 1194 North Mathilda Avenue 1603 Sunnyvale, CA 94089 USA 1604 Phone: (919) 807-0023 1605 EMail: pusateri@juniper.net 1607 9. Acknowledgments 1609 The author would like to acknowledge the original designers of the 1610 protocol, Steve Deering, Craig Partridge, and David Waitzman. 1611 Version 3 of the protocol would not have been possible without the 1612 original work of Ajit Thyagarajan and the ongoing (and seemingly 1613 endless) work of Bill Fenner. Credit also goes to Danny Mitzel and 1614 Dave Thaler for the careful review of this document and Nitin Jain, 1615 Dave LeRoy, Charles Mumford, Ravi Shekhar, and Shuching Shieh for 1616 their helpful comments. 1618 10. Appendix A - Constants & Configurable Parameters 1620 The following table provides a summary of the DVMRP timing 1621 parameters: 1623 Parameter Value (seconds) 1624 ---------------------------------------------------------- 1625 Probe Interval 10 1626 Neighbor Time-out Interval 35 1627 Minimum Flash Update Interval 5 1628 Route Report Interval 60 1629 Route Expiration Time 140 1630 Route Hold-down 2 x Route Report Interval 1631 Prune Lifetime variable (< 2 hours) 1632 Prune Retransmission Time 3 with exp. back-off 1633 Graft Retransmission Time 5 with exp. back-off 1634 ---------------------------------------------------------- 1636 Table 2 - Parameter Summary 1638 11. Appendix B - Tracing and Troubleshooting support 1640 There are several packet types used to gather DVMRP specific 1641 information. They are generally used for diagnosing problems or 1642 gathering topology information. The first two messages are now 1643 obsoleted and should not be used. The remaining two messages provide 1644 a request/response mechanism to determine the versions and 1645 capabilities of a particular DVMRP router. 1647 Code Packet Type Description 1648 ----------------------------------------------------------- 1649 3 DVMRP Ask Neighbors Obsolete 1650 4 DVMRP Neighbors Obsolete 1651 5 DVMRP Ask Neighbors 2 Request Neighbor List 1652 6 DVMRP Neighbors 2 Respond with Neighbor List 1653 ----------------------------------------------------------- 1655 Table 3 - Debugging Packet Types 1657 11.1. DVMRP Ask Neighbors2 1659 The Ask Neighbors2 packet is a unicast request packet directed at a 1660 DVMRP router. The destination should respond with a unicast 1661 Neighbors2 message back to the sender of the Ask Neighbors2 message. 1663 0 8 16 31 1664 +---------+---------+--------------------+ 1665 | Type | Code | Checksum | 1666 |(0x13) | (0x5) | | 1667 +---------+---------+----------+---------+ 1668 | Reserved | Minor | Major | 1669 | | Version |Version | 1670 +-------------------+----------+---------+ 1672 Figure 8 - Ask Neighbors 2 Packet Format 1674 11.2. DVMRP Neighbors2 1676 The format of a Neighbors2 response packet is shown below. This is 1677 sent as a unicast message back to the sender of an Ask Neighbors2 1678 message. There is a common header at the top followed by the routers 1679 capabilities. One or more sections follow that contain an entry for 1680 each logical interface. The interface parameters are listed along 1681 with a variable list of neighbors learned on each interface. 1683 If the interface is down or disabled, list a single neighbor with an 1684 address of 0.0.0.0 for physical interfaces or the remote tunnel 1685 endpoint address for tunnel pseudo-interfaces. 1687 0 8 16 31 1688 +-----------+--------------+--------------------------+ 1689 | Type | Code | Checksum | 1690 | (0x13) | (0x6) | | 1691 +-----------+--------------+------------+-------------+ 1692 | Reserved | Capabilities | Minor | Major | 1693 | | | Version | Version | 1694 +-----------+--------------+------------+-------------+ 1695 | | 1696 | Local Addr 1 | 1697 +-----------+--------------+------------+-------------+ 1698 | | | | | 1699 | Metric 1 | Threshold 1 | Flags 1 | Nbr Count 1 | 1700 +-----------+--------------+------------+-------------+ 1701 | | 1702 | Nbr 1 | 1703 +-----------------------------------------------------+ 1704 | | 1705 | ... | 1706 +-----------------------------------------------------+ 1707 | | 1708 | Nbr m | 1709 +-----------------------------------------------------+ 1710 | | 1711 | Local Addr N | 1712 +-----------+--------------+------------+-------------+ 1713 | | | | | 1714 | Metric N | Threshold N | Flags N | Nbr Count N | 1715 +-----------+--------------+------------+-------------+ 1716 | | 1717 | Nbr 1 | 1718 +-----------------------------------------------------+ 1719 | | 1720 | ... | 1721 +-----------------------------------------------------+ 1722 | | 1723 | Nbr k | 1724 +-----------------------------------------------------+ 1726 Figure 9 - Neighbors 2 Packet Format 1728 The capabilities of the local router are defined as follows: 1730 Bit Flag Description 1731 --------------------------------------------------- 1733 0 Leaf This is a leaf router 1735 1 Prune This router understands pruning 1737 2 GenID This router sends Generation Id's 1739 3 Mtrace This router handles Mtrace requests 1741 4 Snmp This router supports the DVMRP MIB 1742 --------------------------------------------------- 1744 Table 4 - DVMRP Router Capabilities 1746 The flags associated with a particular interface are: 1748 Bit Flag Description 1749 ---------------------------------------------------------- 1751 0 Tunnel Neighbor reached via tunnel 1753 1 Source Route Tunnel uses IP source routing 1755 2 Reserved No longer used 1757 3 Reserved No longer used 1759 4 Down Operational status down 1761 5 Disabled Administrative status down 1763 6 Querier Querier for interface 1765 7 Leaf No downstream neighbors on interface 1766 ---------------------------------------------------------- 1768 Table 5 - DVMRP Interface flags 1770 12. Appendix C - Version Compatibility 1772 There have been two previous major versions of DVMRP with 1773 implementations still in circulation. If the receipt of a Probe 1774 message reveals a major version of 1 or 2, then it can be assumed 1775 that this neighbor does not support pruning or the use of the 1776 Generation ID in the Probe message. However, since these older 1777 implementations are known to safely ignore the Generation ID and 1778 neighbor information in the Probe packet, it is not necessary to send 1779 specially formatted Probe packets to these neighbors. 1781 There were three minor versions (0, 1, and 2) of major version 3 that 1782 did support pruning but did not support the Generation ID or 1783 capability flags. These special cases will have to be accounted for. 1785 Any other minor versions of major version 3 closely compare to this 1786 specification. 1788 In addition, cisco Systems is known to use their software major and 1789 minor release number as the DVMRP major and minor version number. 1790 These will typically be 10 or 11 for the major version number. 1791 Pruning was introduced in Version 11. 1793 Implementations prior to this specification may not wait to send 1794 route reports until probe messages have been received with the 1795 routers address listed. Reports SHOULD be sent to these neighbors 1796 without first requiring a received probe with the routers address in 1797 it as well as reports from these neighbors SHOULD be accepted. 1798 Although, this allows one-way neighbor relationships to occur, it 1799 does maintain backward compatibility. 1801 It may be necessary to form neighbor relationships based solely on 1802 Route Report messages. Neighbor time-out values may need to be 1803 configured to a value greater than the Route Report Interval for 1804 these neighbors. 1806 Implementations that do not monitor Generation ID changes can create 1807 more noticeable black holes when using long prune lifetimes such as 1808 ~2 hours. This happens when a long prune is sent upstream and then 1809 the router that sent the long prune restarts. If the upstream router 1810 ignores the new Generation ID, the prune received by the upstream 1811 router will not be flushed and the downstream router will have no 1812 knowledge of the upstream prune. For this reason, prunes sent 1813 upstream to routers that are known to ignore Generation ID changes 1814 should have short lifetimes. 1816 If the router must run IGMP version 1 on an interface for backwards 1817 compatibility, DVMRP must elect the DVMRP router with the highest IP 1818 address as the IGMP querier. 1820 Some implementations of tools that send DVMRP Ask Neighbors2 requests 1821 and receive Neighbors2 response messages require a neighbor address 1822 of 0.0.0.0 when no neighbors are listed in the response packet. 1823 (Mrinfo) 1825 When DVMRP protocol packets are sent to tunnel endpoints, some 1826 implementations do not accept packets addressed to the All-DVMRP- 1827 Routers address and then encapsulated with the tunnel endpoint 1828 address. Mrouted versions 3.9beta2 and earlier are known to have 1829 this problem. 1831 13. Intellectual Property Rights Notice 1833 The IETF takes no position regarding the validity or scope of any 1834 intellectual property or other rights that might be claimed to 1835 pertain to the implementation or use of the technology described in 1836 this document or the extent to which any license under such rights 1837 might or might not be available; neither does it represent that it 1838 has made any effort to identify any such rights. Information on the 1839 IETF's procedures with respect to rights in standards-track and 1840 standards-related documentation can be found in BCP-11. Copies of 1841 claims of rights made available for publication and any assurances of 1842 licenses to be made available, or the result of an attempt made to 1843 obtain a general license or permission for the use of such 1844 proprietary rights by implementors or users of this specification can 1845 be obtained from the IETF Secretariat. 1847 The IETF invites any interested party to bring to its attention any 1848 copyrights, patents or patent applications, or other proprietary 1849 rights which may cover technology that may be required to practice 1850 this standard. Please address the information to the IETF Executive 1851 Director. 1853 14. Full Copyright Statement 1855 Copyright (C) The Internet Society (date). All Rights Reserved. 1857 This document and translations of it may be copied and furnished to 1858 others, and derivative works that comment on or otherwise explain it 1859 or assist in its implementation may be prepared, copied, published 1860 and distributed, in whole or in part, without restriction of any 1861 kind, provided that the above copyright notice and this paragraph are 1862 included on all such copies and derivative works. However, this 1863 document itself may not be modified in any way, such as by removing 1864 the copyright notice or references to the Internet Society or other 1865 Internet organizations, except as needed for the purpose of 1866 developing Internet standards in which case the procedures for 1867 copyrights defined in the Internet Standards process must be 1868 followed, or as required to translate it into languages other than 1869 English. 1871 The limited permissions granted above are perpetual and will not be 1872 revoked by the Internet Society or its successors or assigns. 1874 This document and the information contained herein is provided on an 1875 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1876 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1877 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1878 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1879 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1881 Table of Contents 1883 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1884 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . . 2 1885 1.2. Reverse Path Multicasting . . . . . . . . . . . . . . . . . 2 1886 1.3. Tunnel Encapsulation . . . . . . . . . . . . . . . . . . . . 2 1887 1.4. Document Overview . . . . . . . . . . . . . . . . . . . . . 3 1888 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 1889 2.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . 4 1890 2.2. Source Location . . . . . . . . . . . . . . . . . . . . . . 4 1891 2.3. Dependent Downstream Routers . . . . . . . . . . . . . . . . 5 1892 2.4. Designated Forwarder . . . . . . . . . . . . . . . . . . . . 6 1893 2.5. Building Multicast Trees . . . . . . . . . . . . . . . . . . 6 1894 2.6. Pruning Multicast Trees . . . . . . . . . . . . . . . . . . 7 1895 2.7. Grafting Multicast Trees . . . . . . . . . . . . . . . . . . 8 1896 3. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 8 1897 3.1. Protocol Header . . . . . . . . . . . . . . . . . . . . . . 8 1898 3.2. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . 10 1899 3.3. Multicast Forwarding . . . . . . . . . . . . . . . . . . . . 15 1900 3.4. Route Exchange . . . . . . . . . . . . . . . . . . . . . . . 16 1901 3.5. Pruning . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1902 3.6. Grafting . . . . . . . . . . . . . . . . . . . . . . . . . . 30 1903 3.7. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 34 1904 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 1905 5. Network Management Considerations . . . . . . . . . . . . . . 35 1906 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 1907 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 1908 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 39 1909 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 1910 10. Appendix A - Constants & Configurable Parameters . . . . . . 40 1911 11. Appendix B - Tracing and Troubleshooting support . . . . . . 41 1912 11.1. DVMRP Ask Neighbors2 . . . . . . . . . . . . . . . . . . . 41 1913 11.2. DVMRP Neighbors2 . . . . . . . . . . . . . . . . . . . . . 42 1914 12. Appendix C - Version Compatibility . . . . . . . . . . . . . 46 1915 13. Intellectual Property Rights Notice . . . . . . . . . . . . . 48 1916 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 48 1918 Attachment Converted: "c:\program files\qualcomm\eudora\imap\dominant\ids\attach\Untitled"