idnits 2.17.1 draft-ietf-idmr-dvmrp-v3-10.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. ** 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 49: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 50: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 135: '... MUST be set to 1....' RFC 2119 keyword, line 369: '...e. The checksum MUST be calculated up...' RFC 2119 keyword, line 370: '...transmission and MUST be validated on ...' (36 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 327 has weird spacing: '...ets are encap...' == Line 360 has weird spacing: '...aft Ack for ...' == Line 1813 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 (August 2000) is 8655 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 52, but not defined -- Looks like a reference, but probably isn't: '00' on line 738 ** 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 2406 (ref. 'Ken98c') (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. 'McCl00' -- 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: 15 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 T. Pusateri 3 INTERNET DRAFT Juniper Networks 4 Obsoletes: RFC 1075 August 2000 5 draft-ietf-idmr-dvmrp-v3-10 Expires: February 4, 2001 7 Distance Vector Multicast Routing Protocol 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 DVMRP is an Internet routing protocol that provides an efficient 33 mechanism for connection-less datagram delivery to a group of hosts 34 across an internetwork. It is a distributed protocol that dynamically 35 generates IP Multicast delivery trees using a technique called 36 Reverse Path Multicasting (RPM) [Deer90]. This document is an update 37 to Version 1 of the protocol specified in RFC 1075 [Wait88]. 39 1. Introduction 41 DVMRP uses a distance vector distributed routing algorithm in order 42 to build per-source-group multicast delivery trees. A good 43 introduction to distance vector routing can be found in [Perl92]. 44 The application of distance vector routing to multicast tree 45 formulation is described in [Deer91]. 47 1.1. Requirements Terminology 49 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 50 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 51 document, are to be interpreted as described in [RFC-2119]. 53 1.2. Reverse Path Multicasting 55 Datagrams follow multicast delivery trees from a source to all 56 members of a multicast group [Deer89], replicating the packet only at 57 necessary branches in the delivery tree. The trees are calculated and 58 updated dynamically to track the membership of individual groups. 59 When a datagram arrives on an interface, the reverse path to the 60 source of the datagram is determined by examining a DVMRP routing 61 table of known source networks. If the datagram arrives on an 62 interface that would be used to transmit datagrams back to the 63 source, then it is forwarded to the appropriate list of downstream 64 interfaces. Otherwise, it is not on the optimal delivery tree and 65 should be discarded. In this way duplicate packets can be filtered 66 when loops exist in the network topology. The source specific 67 delivery trees are automatically pruned back as group membership 68 changes or routers determine that no group members are present. This 69 keeps the delivery trees to the minimum branches necessary to reach 70 all of the group members. New sections of the tree can also be added 71 dynamically as new members join the multicast group by grafting the 72 new sections onto the delivery trees. 74 1.3. Tunnel Encapsulation 76 Because not all IP routers support native multicast routing, DVMRP 77 includes direct support for tunneling IP Multicast datagrams through 78 routers. The IP Multicast datagrams are encapsulated in unicast IP 79 packets and addressed to the routers that do support native multicast 80 routing. DVMRP treats tunnel interfaces in an identical manner to 81 physical network interfaces. 83 In previous implementations, DVMRP protocol messages were sent un- 84 encapsulated to the unicast tunnel endpoint address. While this was 85 more direct, it increased the complexity of firewall configuration. 86 The most noticeable change in this specification regarding tunnels is 87 that all DVMRP protocol messages should be sent encapsulated across 88 the tunnel. Previously, protocol messages were sent un-encapsulated 89 directly to the tunnel endpoint. See Appendix C for backward 90 compatibility issues. 92 Note: All protocol messages sent on point-to-point links (including 93 tunnels) should use a destination address of All-DVMRP-Routers. This 94 change will allow the protocol messages to be forwarded across 95 multicast-only tunnels without making encapsulation and decapsulation 96 difficult. 98 In practice, tunnels typically use either IP-IP [Perk96] or Generic 99 Routing Encapsulation (GRE) [Han94a,Han94b], although, other 100 encapsulation methods are acceptable. 102 1.4. Document Overview 104 Section 2 provides an overview of the protocol and the different 105 message types exchanged by DVMRP routers. Those who wish to gain a 106 general understanding of the protocol but are not interested in the 107 more precise details may wish to only read this section. Section 3 108 explains the detailed operation of the protocol to accommodate 109 developers needing to provide inter-operable implementations. 110 Included in Appendix A, is a summary of the DVMRP parameters. A 111 section on DVMRP support for tracing and troubleshooting is the topic 112 of Appendix B. Finally, a short DVMRP version compatibility section 113 is provided in Appendix C to assist with backward compatibility 114 issues. 116 2. Protocol Overview 118 DVMRP can be summarized as a "broadcast & prune" multicast routing 119 protocol. It builds per-source broadcast trees based upon routing 120 exchanges, then dynamically creates per-source-group multicast 121 delivery trees by pruning (removing branches from) the source's 122 truncated broadcast tree. It performs Reverse Path Forwarding checks 123 to determine when multicast traffic should be forwarded to downstream 124 interfaces. In this way, source-rooted shortest path trees can be 125 formed to reach all group members from each source network of 126 multicast traffic. 128 2.1. Neighbor Discovery 130 Neighbor DVMRP routers are discovered dynamically by sending Neighbor 131 Probe Messages on local multicast capable network interfaces and 132 tunnel pseudo interfaces. These messages are sent periodically to the 133 All-DVMRP-Routers [Reyn94] IP Multicast group address. (See Appendix 134 C for backwards compatibility issues.) The IP TTL of these messages 135 MUST be set to 1. 137 Each Neighbor Probe message contains the list of Neighbor DVMRP 138 routers for which Neighbor Probe messages have been received on that 139 interface. In this way, Neighbor DVMRP routers can ensure that they 140 are seen by each other. 142 Once you have received a Probe from a neighbor that contains your 143 address in the neighbor list, you have established a two-way neighbor 144 adjacency with this router. 146 2.2. Source Location 148 When an IP Multicast datagram is received by a router running DVMRP, 149 it first looks up the source network in the DVMRP routing table. The 150 interface on which the best route to the source of the datagram was 151 received is called the upstream (also called RPF) interface. If the 152 datagram arrived on the correct upstream interface, then it is a 153 candidate for forwarding to one or more downstream interfaces. If the 154 datagram did not arrive on the anticipated upstream interface, it is 155 discarded. This check is known as a reverse path forwarding check and 156 must be performed by all DVMRP routers. 158 In order to ensure that all DVMRP routers have a consistent view of 159 the path back to a source, a routing table is propagated to all DVMRP 160 routers as an integral part of the protocol. Each router advertises 161 the network number and mask of the interfaces it is directly 162 connected to as well as relaying the routes received from neighbor 163 routers. DVMRP requires an interface metric to be configured on all 164 physical and tunnel interfaces. When a route is received, the metric 165 of the interface over which the datagram was received must be added 166 to the metric of the route being advertised in the route report 167 message. This adjusted metric should be used when comparing metrics 168 to determine the best upstream neighbor. 170 Although there is certainly additional overhead associated with 171 propagating a separate DVMRP routing table, it does provide two nice 172 features. First, since all DVMRP routers are exchanging the same 173 routes, there are no inconsistencies between routers when determining 174 the upstream interface (aside from normal convergence issues related 175 to distance vector routing protocols). By placing the burden of 176 synchronization on the protocol as opposed to the network manager, 177 DVMRP reduces the risk of creating routing loops or black holes due 178 to disagreement between neighbor routers on the upstream interface. 180 Second, by propagating its own routing table, DVMRP makes it 181 convenient to have separate paths for unicast versus multicast 182 datagrams. Although, ideally, many network managers would prefer to 183 keep their unicast and multicast traffic aligned, tunneled multicast 184 topologies may prevent this causing the unicast and multicast paths 185 to diverge. Additionally, service providers may prefer to keep the 186 unicast and multicast traffic separate for routing policy reasons as 187 they experiment with IP multicast routing and begin to offer it as a 188 service. 190 2.3. Dependent Downstream Routers 192 In addition to providing a consistent view of source networks, the 193 exchange of routes in DVMRP provides one other important feature. 194 DVMRP uses the route exchange as a mechanism for upstream routers to 195 determine if any downstream routers depend on them for forwarding 196 from particular source networks. DVMRP accomplishes this by using a 197 technique called "Poison Reverse". If a downstream router selects an 198 upstream router as the best next hop to a particular source network, 199 this is indicated by echoing back the route on the upstream interface 200 with a metric equal to the original metric plus infinity. When the 201 upstream router receives the report and sees a metric that lies 202 between infinity and twice infinity, it can then add the downstream 203 router from which it received the report to a list of dependent 204 routers for this source. 206 This list of dependent routers per source network built by the 207 "Poison Reverse" technique will provide the foundation necessary to 208 determine when it is appropriate to prune back the IP source specific 209 multicast trees. 211 2.4. Designated Forwarder 213 When two or more multicast routers are connected to a multi-access 214 network, it could be possible for duplicate packets to be forwarded 215 on the network (one copy from each router). DVMRP prevents this 216 possibility by electing a forwarder for each source as a side effect 217 of its route exchange. When two routers on a multi-access network 218 exchange source networks, each of the routers will know the others 219 metric back to each source network. Therefore, of all the DVMRP 220 routers on a shared network, the router with the lowest metric to a 221 source network is responsible for forwarding data on to the shared 222 network. If two or more routers have an equally low metric, the 223 router with the lowest IP address becomes the designated forwarder 224 for the network. In this way, DVMRP does an implicit designated 225 forwarder election for each source network on each downstream 226 interface. 228 2.5. Building Multicast Trees 230 As previously mentioned, when an IP multicast datagram arrives, the 231 upstream interface is determined by looking up the interface on which 232 the best route to the source of the datagram was received. If the 233 upstream interface is correct, then a DVMRP router will forward the 234 datagram to a list of downstream interfaces. 236 2.5.1. Adding Local Group Members 238 The IGMP local group database is maintained by all IP multicast 239 routers on each physical, multicast capable network [Fenn97]. If the 240 destination group address is listed in the local group database, and 241 the router is the designated forwarder for the source, then the 242 interface is included in the list of downstream interfaces. If there 243 are no group members on the interface, then the interface is removed 244 from the outgoing interface list. 246 2.5.2. Adding Interfaces with Neighbors 248 Initially, all interfaces with downstream dependent neighbors should 249 be included in the downstream interface list when a forwarding cache 250 entry is first created. This allows the downstream routers to be 251 aware of traffic destined for a particular (source network, group) 252 pair. The downstream routers will then have the option to send prunes 253 and subsequent grafts for this (source network, group) pair as 254 requirements change from their respective downstream routers and 255 local group members. 257 2.6. Pruning Multicast Trees 259 As mentioned above, routers at the edges will remove their interfaces 260 that have no group members associated with an IP multicast datagram. 261 If a router removes all of its downstream interfaces, it notifies the 262 upstream router that it no longer wants traffic destined for a 263 particular (source network, group) pair. This is accomplished by 264 sending a DVMRP Prune message upstream to the router it expects to 265 forward datagrams from a particular source. 267 Recall that a downstream router will inform an upstream router that 268 it depends on the upstream router to receive datagrams from 269 particular source networks by using the "Poison Reverse" technique 270 during the exchange of DVMRP routes. This method allows the upstream 271 router to build a list of downstream routers on each interface that 272 are dependent upon it for datagrams from a particular source network. 273 If the upstream router receives prune messages from each one of the 274 dependent downstream routers on an interface, then the upstream 275 router can in turn remove this interface from its downstream 276 interface list. If the upstream router is able to remove all of its 277 downstream interfaces in this way, it can then send a DVMRP Prune 278 message to its upstream router. This continues until the unneeded 279 branches are removed from the delivery tree. 281 In order to remove old prune state information for (source network, 282 group) pairs that are no longer active, it is necessary to limit the 283 life of a prune and periodically resume the broadcasting procedure. 284 The prune message contains a prune lifetime, indicating the length of 285 time that the prune should remain in effect. When the prune lifetime 286 expires, the interface is joined back onto the multicast delivery 287 tree. If unwanted multicast datagrams continue to arrive, the prune 288 mechanism will be re-initiated and the cycle will continue. If all 289 of the downstream interfaces are removed from a multicast delivery 290 tree causing a DVMRP Prune message to be sent upstream, the lifetime 291 of the prune sent must be equal to the minimum of the remaining 292 lifetimes of the received prunes. 294 2.7. Grafting Multicast Trees 296 Once a tree branch has been pruned from a multicast delivery tree, 297 packets from the corresponding (source network, group) pair will no 298 longer be forwarded. However, since IP multicast supports dynamic 299 group membership, hosts may join a multicast group at any time. In 300 this case, DVMRP routers use Grafts to cancel the prunes that are in 301 place from the host back on to the multicast delivery tree. A router 302 will send a Graft message to its upstream neighbor if a group join 303 occurs for a group that the router has previously sent a prune. 304 Separate Graft messages must be sent to the appropriate upstream 305 neighbor for each source network that has been pruned. Since there 306 would be no way to tell if a Graft message sent upstream was lost or 307 the source simply quit sending traffic, it is necessary to 308 acknowledge each Graft message with a DVMRP Graft Ack message. If an 309 acknowledgment is not received within a Graft Time-out period, the 310 Graft message should be retransmitted using binary exponential back- 311 off between retransmissions. Duplicate Graft Ack messages should 312 simply be ignored. The purpose of the Graft Ack message is to simply 313 acknowledge the receipt of a Graft message. It does not imply that 314 any action was taken as a result of receiving the Graft message. 315 Therefore, all Graft messages received from a neighbor with whom a 316 two-way neighbor relationship has been formed should be acknowledged 317 whether or not they cause an action on the receiving router. 319 3. Detailed Protocol Operation 321 This section contains a detailed description of DVMRP. It covers 322 sending and receiving of DVMRP messages as well as the generation and 323 maintenance of IP Multicast forwarding cache entries. 325 3.1. Protocol Header 327 DVMRP packets are encapsulated in IP datagrams, with an IP protocol 328 number of 2 (IGMP) as specified in the Assigned Numbers RFC [Reyn94]. 329 All fields are transmitted in Network Byte Order. DVMRP packets use a 330 common protocol header that specifies the IGMP [Fenn97] Packet Type 331 as hexadecimal 0x13 (DVMRP). DVMRP protocol packets should be sent 332 with the Precedence field in the IP header set to Internetwork 333 Control (hexadecimal 0xc0 for the Type of Service Octet) [Post81]. A 334 diagram of the common protocol header follows: 336 0 8 16 31 337 +---------+---------+--------------------+ 338 | Type | Code | Checksum | 339 |(0x13) | | | 340 +---------+---------+----------+---------+ 341 | Reserved | Minor | Major | 342 | | Version |Version | 343 +-------------------+----------+---------+ 345 Figure 1 - Common Protocol Header 347 A Major Version of 3 and a Minor Version of 0xFF should be used to 348 indicate compliance with this specification. The value of the Code 349 field determines the DVMRP packet type. Currently, there are codes 350 allocated for DVMRP protocol message types as well as protocol 351 analysis and troubleshooting packets. The protocol message Codes 352 are: 354 Code Packet Type Description 355 ---------------------------------------------------------------- 356 1 DVMRP Probe for neighbor discovery 357 2 DVMRP Report for route exchange 358 7 DVMRP Prune for pruning multicast delivery trees 359 8 DVMRP Graft for grafting multicast delivery trees 360 9 DVMRP Graft Ack for acknowledging graft messages 361 ---------------------------------------------------------------- 363 Table 1 - Standard Protocol Packet Types 365 There are additional codes used for protocol analysis and 366 troubleshooting. These codes are discussed in Appendix B. 368 The Checksum is the 16-bit one's complement of the one's complement 369 sum of the DVMRP message. The checksum MUST be calculated upon 370 transmission and MUST be validated on reception of a packet. The 371 checksum of the DVMRP message is calculated with the checksum field 372 set to zero. See [Brad88] for more information. 374 3.2. Probe Messages 376 When a DVMRP router is configured to run on an interface (physical or 377 tunnel), it multicasts DVMRP Probe packets to inform other DVMRP 378 routers that it is operational. Effectively, they serve three 379 purposes. 381 1. Probes provide a mechanism for DVMRP routers to locate each other. 382 DVMRP sends on each interface, a Probe Message containing the list 383 of the neighbors detected for that specific interface. If no 384 DVMRP neighbors are found, the network is considered to be a leaf 385 network. 387 2. Probes provide a way for DVMRP routers to determine the 388 capabilities of each other. This may be deduced from the major and 389 minor version numbers in the Probe packet or directly from the 390 capability flags. These flags were first introduced to allow 391 optional protocol features. This specification now mandates the 392 use of Generation Id's and pruning and, therefore, provides no 393 optional capabilities. Other capability flags were used for 394 tracing and troubleshooting and are no longer a part of the actual 395 protocol. 397 3. Probes provide a keep-alive function in order to quickly detect 398 neighbor loss. Probes sent on each multicast capable interface 399 configured for DVMRP SHOULD use an interval of 10 seconds. The 400 neighbor time-out interval SHOULD be set at 35 seconds. This 401 allows fairly early detection of a lost neighbor yet provides 402 tolerance for busy multicast routers. These values MUST be 403 coordinated between all DVMRP routers on a physical network 404 segment. 406 3.2.1. Router Capabilities 408 In the past, there have been many versions of DVMRP in use with a 409 wide range of capabilities. Practical considerations require a 410 current implementation to inter-operate with these older 411 implementations that don't formally specify their capabilities and 412 are not compliant with this specification. For instance, for major 413 versions less than 3, it can be assumed that the neighbor does not 414 support pruning. The formal capability flags were first introduced 415 in an well known implementation (Mrouted version 3.5) in an attempt 416 to take the guess work out which features are supported by a 417 neighbor. Many of these flags are no longer necessary since they are 418 now a required part of the protocol, however, special consideration 419 is necessary to not confuse older implementations that expect these 420 flags to be set. Appendix C was written to assist with these and 421 other backward compatibility issues. 423 Three of the flags were used for actual protocol operation. The 424 other two assigned flags were used for troubleshooting purposes which 425 should be documented in a separate specification. All of the bits 426 marked "U" in the Figure below are now unused. They may be defined in 427 the future and MUST be set to 0 on transmission and ignored on 428 reception. Bit position 0 is the LEAF bit which is a current research 429 topic. It MUST be set to 0 and ignored on reception. Bit positions 430 1, 2, and 3 MUST be set to 1 for backward compatibility. They were 431 used to specify the PRUNE, GENID, and MTRACE bits. The first two, 432 PRUNE and GENID, are now required features. The MTRACE bit must be 433 set so existing implementations will not assume this neighbor does 434 not support multicast trace-route [Fenn00]. However, since this bit 435 is now reserved and set to 1, newer implementations should not use 436 this bit in the Probe message to determine if multicast trace-route 437 is supported by a neighbor. Instead, the M bit should only be used in 438 a Neighbors2 message as described in Appendix B. The bit marked S 439 stands for SNMP capable. This bit is used by troubleshooting 440 applications and should only be tested in the Neighbors2 message. 442 The N bit (which stands for Netmask) is defined by this 443 specification. It is used to indicate the neighbor will accept 444 network masks appended to the Prune, Graft, and Graft Ack messages. 445 This bit only indicates that the neighbor understands the netmask. It 446 DOES NOT mean that Prune, Graft, and Graft Ack messages sent to this 447 neighbor must include a netmask. Refer to the sections on Prune, 448 Graft, and Graft Ack messages for more details. 450 Each time a Probe message is received from a neighbor, the 451 capabilities bits should be compared to the previous version for that 452 neighbor in order to detect changes in neighbor capabilities. 454 7 6 5 4 3 2 1 0 455 U U N S M G P L 456 +---+---+---+---+----+---+---+---+ 457 |0 |0 |X | 0 | 1 |1 |1 | 0 | 458 +---+---+---+---+----+---+---+---+ 460 Figure 2 - Probe Capability Flags 462 3.2.2. Generation ID 464 If a DVMRP router is restarted, it will not be aware of any previous 465 prunes that it had sent or received. In order for the neighbor to 466 detect that the router has restarted, a non-decreasing number is 467 placed in the periodic probe message called the generation ID. When 468 a change in the generation ID is detected, any prune information 469 received from the router is no longer valid and should be flushed. 470 If this prune state has caused prune information to be sent upstream, 471 a graft will need to be sent upstream just as though a new member has 472 joined below. Once data begins to be delivered downstream, if the 473 downstream router again decides to be pruned from the delivery tree, 474 a new prune can be sent upstream at that time. 476 In addition, the effects of a restart can be minimized if the router 477 can learn all of the routes known by its neighbors without having to 478 wait for an entire report interval to pass. When a router detects a 479 change in the generation ID of a neighbor, it should send a unicast 480 copy of its entire routing table to the neighbor. 482 In addition to restarting, a router may also miss prune information 483 while an interface has transitioned to a down state. Therefore, a 484 change in the generation ID is necessary when an interface 485 transitions to the up state. In order to prevent all prune state from 486 being flushed on a router when a single interface transitions, a 487 DVMRP router should keep seperate generation ID numbers per 488 interface. 490 A time of day clock provides a good source for a non-decreasing 32 491 bit integer. 493 3.2.3. Neighbor Addresses 495 As a DVMRP router sees Probe messages from its DVMRP neighbors, it 496 records the neighbor addresses on each interface and places them in 497 the Probe message sent on the particular interface. This allows the 498 neighbor router to know that its probes have been received by the 499 sending router. 501 In order to minimize one-way neighbor relationships, a router MUST 502 delay sending poison route reports in response to routes advertised 503 by a neighbor until the neighbor includes the routers address in its 504 probe messages. On point-to-point interfaces and tunnel pseudo- 505 interfaces, this means that no packets should be forwarded onto these 506 interfaces until two-way neighbor relationships have formed. 508 Implementations written before this specification will not wait 509 before sending reports nor will they ignore reports sent. Therefore, 510 reports from these implementations SHOULD be accepted whether or not 511 a probe with the routers address has been received. 513 3.2.4. Neighbor Expiry 515 When a neighbor expires, the following steps should be taken: 517 1. All routes learned from this neighbor should be immediately placed 518 in hold-down. All downstream dependencies ON this neighbor should 519 be removed. 521 2. If this neighbor is considered to be the designated forwarder for 522 any of the routes it is advertising, a new designated forwarder 523 for each source network should be selected. 525 3. Any forwarding cache entries based on this upstream neighbor 526 should be flushed. 528 4. Any outstanding Grafts awaiting acknowledgments from this router 529 should be flushed. 531 5. All downstream dependencies received FROM this neighbor should be 532 removed. Forwarding cache entries should be checked to see if 533 this is the last downstream dependent neighbor on the interface. 534 If so, and this router isn't the designated forwarder (with local 535 group members present), the interface should be removed. 537 It is possible as an optimization to send a prune upstream if this 538 causes the last downstream interface to be removed. However, this 539 prune could be unnecessary if no more traffic is arriving. It is 540 also acceptable to simply wait for traffic to arrive before 541 sending the prune upstream. 543 3.2.5. Probe Packet Format 545 The Probe packet is variable in length depending on the number of 546 neighbor IP addresses included. The length of the IP packet can be 547 used to determine the number of neighbors in the Probe message. The 548 current Major Version is 3. 550 7 15 23 31 551 +---------+--------------+--------------------+ 552 | Type | Code | Checksum | 553 | (0x13) | (0x1) | | 554 +---------+--------------+----------+---------+ 555 | | | | | 556 |Reserved | Capabilities | Minor | Major | 557 +---------+--------------+----------+---------+ 558 | | 559 | Generation ID | 560 +---------------------------------------------+ 561 | | 562 | Neighbor IP Address 1 | 563 +---------------------------------------------+ 564 | | 565 | Neighbor IP Address 2 | 566 +---------------------------------------------+ 567 | | 568 | ... | 569 +---------------------------------------------+ 570 | | 571 | Neighbor IP Address N | 572 +---------------------------------------------+ 574 Figure 3 - DVMRP Probe Packet Format 576 Generation ID 577 This field contains a non-decreasing number used to detect a 578 change in neighbor state. 580 Neighbor IP Address N 581 This is a list of Neighbor IP addresses whom the sending router 582 has received Probe messages from. 584 3.2.6. IGMP Designated Querier Election 586 Since it is wasteful to have more than a single router sending IGMP 587 Host Membership Queries on a given physical network, a single router 588 on each physical network is elected as the Designated Querier. This 589 election was formerly a part of DVMRP. However, this is now 590 specified as a part of the IGMP version 2 protocol. See Appendix C 591 for details on backwards compatibility. 593 Even though only one router will act as the IGMP designated querier, 594 all DVMRP routers must use IGMP to learn local group memberships. 596 3.3. Multicast Forwarding 598 DVMRP can forward multicast packets by building the downstream 599 interface list for each packet as it arrives. However, to reduce per 600 packet processing time, the result of the first lookup MAY be cached 601 in a forwarding table. Then, as routes, downstream dependent 602 neighbors, or group membership change, the cache forwarding table 603 entries MUST be updated to reflect these changes. 605 3.3.1. Designated Forwarder 607 Initially, a DVMRP router should assume it is the designated 608 forwarder for all source networks on all downstream interfaces. As it 609 receives route reports, it can determine if other routers on multi- 610 access networks have better routes back to a particular source 611 network. A route is considered better if the adjusted received metric 612 is less than the metric that it will advertise for the source network 613 on the received interface or if the metrics are the same but the IP 614 address of the neighbor is lower. 616 If this neighbor becomes unreachable or starts advertising a worse 617 metric, then the router should become the designated forwarder for 618 this source network again on the downstream interface until it hears 619 from a better candidate. 621 If the upstream RPF interface changes, then the router should become 622 the designated forwarder on the previous upstream interface (which is 623 now a potential downstream interface) until it hears from a better 624 candidate. 626 3.3.2. Determining the upstream interface 628 When a multicast packet arrives, a DVMRP router will use the DVMRP 629 routing table to determine which interface leads back to the source. 630 If the packet did not arrive on that interface, it MUST be discarded 631 without further processing. Each multicast forwarding entry should 632 cache the upstream interface for a particular source host or source 633 network after looking this up in the DVMRP routing table. 635 3.3.3. Determining the downstream interface list 637 The downstream interface list is built by starting with the list of 638 non-leaf interfaces. The upstream interface MUST be removed from this 639 list. Then any interfaces on the list where all of the downstream 640 dependents have sent prunes upstream MUST be removed. Next, any 641 interfaces for which the router is the designated forwarder and local 642 group members are present MUST be added to the list. 644 3.4. Route Exchange 646 The routing information propagated by DVMRP is used for determining 647 the reverse path neighbor back to the source of the multicast 648 traffic. The interface used to reach this neighbor is called the 649 upstream interface. Tunnel pseudo-interfaces are considered to be 650 distinct from the physical interface on which the packet is actually 651 transmitted for the purpose of determining upstream and downstream 652 interfaces. 654 The routing information that is propagated by DVMRP contains a list 655 of source networks and an appropriate metric. The metric used is a 656 hop count which is incremented by the cost of the incoming interface 657 metric. Traditionally, physical interfaces use a metric of 1 while 658 the metric of a tunnel interface varies with the distance and 659 bandwidth in the path between the two tunnel endpoints. Users are 660 encouraged to configure tunnels with the same metric in each 661 direction to create symmetric routing and provide for easier problem 662 determination although the protocol does not strictly enforce this. 664 3.4.1. Source Network Aggregation 665 Implementations may wish to provide a mechanism to aggregate source 666 networks to reduce the size of the routing table. All implementations 667 should be able to accept reports for aggregated source networks in 668 accordance with Classless Inter-Domain Routing (CIDR) as described in 669 [Rekh93] and [Full93]. 671 There are two places where aggregation is particularly useful. 673 1. At organizational boundaries to limit the number of source 674 networks advertised out of the organization. 676 2. Within an organization to summarize non-local routing information 677 by using a default (0/0) route. 679 If an implementation wishes to support source aggregation, it MUST 680 transmit Prune and Graft messages according to the following rules: 682 A. If a Prune is received on a downstream interface for which the 683 source network advertised to that neighbor is an aggregate, then 684 if a prune is sent upstream, it should only be sent for the 685 contributing route based on the source address in the received 686 prune. 688 If additional data is received for sources within the range of the 689 aggregate, then this SHOULD trigger additional prunes to be sent 690 upstream for these sources. 692 There may be active forwarding cache entries for other 693 contributing routes to the aggregate. Prunes should not be sent 694 upstream to the contributing routes that have no forwarding state. 696 B. If a Graft is received on a downstream interface for which the 697 source network advertised to that neighbor is an aggregate 698 generated by the receiving router, then Graft messages MUST be 699 sent upstream (if necessary) for each route that contributed to 700 the aggregate that had been previously pruned. 702 3.4.2. Route Packing and Ordering 704 Since DVMRP Route Reports may need to refresh several thousand routes 705 each report interval, routers MUST attempt to spread the routes 706 reported across the whole route update interval. This reduces the 707 chance of synchronized route reports causing routers to become 708 overwhelmed for a few seconds each report interval. Since the route 709 report interval is 60 seconds, it is suggested that the total number 710 routes being updated be split across multiple Route Reports sent at 711 regular intervals. There was an earlier requirement that Route 712 Reports MUST contain source network/mask pairs sorted first by 713 increasing network mask and then by increasing source network. This 714 restriction has been lifted. Implementations conforming to this 715 specification MUST be able to receive Route Reports containing any 716 mixture of network masks and source networks. 718 In order to pack more source networks into a route report, source 719 networks are often represented by less than 4 octets. The number of 720 non-zero bytes in the mask value is used to determine the number of 721 octets used to represent each source network within that particular 722 mask value. For instance if the mask value of 255.255.0.0 is being 723 reported, the source networks would only contain 2 octets each. DVMRP 724 assumes that source networks will never be aggregated into networks 725 whose prefix length is less than 8. Therefore, it does not carry the 726 first octet of the mask in the Route Report since, given this 727 assumption, the first octet will always be 0xFF. This means that the 728 netmask value will always be represented in 3 octets. This method of 729 specifying source network masks is compatible with techniques 730 described in [Rekh93] and [Full93] to group traditional Class C 731 networks into super-nets and to allow different subnets of the same 732 Class A network to be discontinuous. It does not, however, allow 733 grouping class A networks into super-nets since the first octet of 734 the netmask is always assumed to be 255. 736 In this notation, the default route is represented as the least three 737 significant octets of the netmask [00 00 00], followed by one octet 738 for the network number [00]. This special case MUST be interpreted 739 as 0.0.0.0/0.0.0.0 and NOT 0.0.0.0/255.0.0.0. 741 3.4.3. Route Metrics 743 For each source network reported, a route metric is associated with 744 the route being reported. The metric is the sum of the interface 745 metrics between the router originating the report and the source 746 network. For the purposes of DVMRP, the Infinity metric is defined to 747 be 32. This limits the breadth across the whole DVMRP network and is 748 necessary to place an upper bound on the convergence time of the 749 protocol. 751 As seen in the packet format below, Route Reports do not contain a 752 count of the number of routes reported for each netmask. Instead, a 753 "Last" bit is defined as the high order bit of the octet following 754 the network address. This bit is set to signify when the last route 755 is being reported for a particular mask value. When the "Last" bit 756 is set and the end of the message has not been reached, the next 757 value will be a new netmask to be applied to the subsequent list of 758 routes. 760 3.4.4. Route Dependencies 762 In order for pruning to work correctly, each DVMRP router needs to 763 know which downstream routers depend on it for receiving datagrams 764 from particular source networks. Initially, when a new datagram 765 arrives from a particular source/group pair, it is broadcasted to all 766 downstream interfaces that have DVMRP neighbors who have indicated a 767 dependency on the receiving DVMRP router for that particular source. 768 A downstream interface can only be removed when the router has 769 received Prune messages from each of the dependent routers on that 770 interface. Each downstream router uses Poison Reverse to indicate 771 for which source networks it is dependent upon the upstream router. 772 The downstream router indicates this by echoing back the source 773 networks it expects to receive from the upstream router with infinity 774 added to the advertised metric. This means that the legal values for 775 the metric now become between 1 and (2 x Infinity - 1) or 1 and 63. 776 Values between 1 and 31 indicate reachable source networks. The value 777 Infinity (32) indicates the source network is not reachable. Values 778 between 33 and 63 indicate that the downstream router originating the 779 Report is depending upon the upstream router to provide multicast 780 datagrams from the corresponding source network. 782 3.4.5. Sending Route Reports 784 All of the active routes MUST be advertised over all interfaces with 785 neighbors present each Route Report Interval. In addition, flash 786 updates MAY be sent as needed but flash updates MUST NOT happen more 787 often than the Minimum Flash Update Interval (5 seconds). Flash 788 updates reduce the chances of routing loops and black holes occurring 789 when source networks become unreachable through a particular path. 790 Flash updates need only contain the source networks that have 791 changed. 793 When a router sees its own address in a neighbor probe packet for the 794 first time, it should send a unicast copy of its entire routing table 795 to the neighbor to reduce start-up time. 797 Reports should not be sent to a neighbor until a router has seen its 798 own address in the neighbors Probe router list. See Appendix C for 799 exceptions. 801 3.4.6. Receiving Route Reports 803 After receiving a route report, a check should be made to verify it 804 is from a known neighbor. Two-way neighbor relationships are 805 essential for proper DVMRP operation. Therefore, route reports from 806 unknown neighbors MUST be discarded. 808 In the following discussion, "Metric" refers to the metric of the 809 route as received in the route report. "Adjusted Metric" refers to 810 the metric of the route after the incoming interface metric has been 811 added. 813 If the metric received is less than infinity but the Adjusted Metric 814 is greater than or equal to infinity, the Adjusted Metric should be 815 set to infinity. 817 If the metric is greater than or equal to infinity, then no 818 adjustment of the metric should be made. 820 Each route in the report is then parsed and processed according to 821 the following rules: 823 A. If the route is new and the Adjusted Metric is less than infinity, 824 the route should be added. 826 B. If the route already exists, several checks must be performed. 828 1. Received Metric < infinity 830 If the neighbor was considered a downstream dependent neighbor, 831 the dependency is canceled. 833 In the following cases, the designated forwarder on one of the 834 downstream interfaces should be updated: 836 - If the Metric received would cause the router to advertise a 837 better metric on a downstream interface than the existing 838 designated forwarder for the source network on that 839 interface (or advertised metric would be the same but the 840 router's IP address is lower than the existing designated 841 forwarder on that interface). Then the receiving router 842 becomes the new designated forwarder for that source network 843 on that interface. If this router had sent a prune upstream 844 that is still active, it will need to send a graft. 846 - If the metric being advertised by the current designated 847 forwarder is worse than the receiving routers metric that it 848 would advertise on the receiving interface (from learning 849 the same route from a neighbor on another interface) or the 850 metric is the same but the receiving router has a lower IP 851 address, then the receiving router becomes the new 852 designated forwarder on that interface. This may trigger a 853 graft to be sent upstream. 855 - If the metric received for the source network is better than 856 the metric of the existing designated forwarder, save the 857 new designated forwarder and the metric it is advertising. 858 It is necessary to maintain knowledge of the current 859 designated forwarder for each source network in case the 860 time-out value for this neighbor is reached. If the time-out 861 is reached, then the designated forwarder responsibility for 862 the source network should be assumed. 864 A route is considered better when either the received Metric is 865 lower than the existing metric or the received Metric is the 866 same but the advertising router's IP address is lower. 868 a. Adjusted Metric > existing metric 870 If the Adjusted Metric is greater than the existing metric, 871 then check to see if the same neighbor is reporting the 872 route. If so, update the route metric and schedule a flash 873 update containing the route. Otherwise, skip to the next 874 route in the report. 876 b. Adjusted Metric < existing metric 878 Update the metric for the route and if the neighbor 879 reporting the route is different, update the upstream 880 neighbor in the routing table. Schedule a flash update 881 containing the route to downstream neighbors and a flash 882 poison update containing the route should be sent upstream 883 indicating a change in downstream dependency (even if its on 884 the same upstream interface). 886 c. Adjusted metric = existing metric 888 If the neighbor reporting the route is the same as the 889 existing upstream neighbor, then simply refresh the route. 891 If the neighbor is the same and the route is in hold-down, 892 it is permissible to prematurely take the route out of hold- 893 down and begin advertising it with a non-infinity metric. 894 If the route is taken out of hold-down, a flash update 895 containing the route should be scheduled on all DVMRP 896 interfaces except the one over which it was received. 898 If the neighbor reporting the route has a lower IP address 899 than the existing upstream neighbor, then switch to this 900 neighbor as the best route. Schedule a flash update 901 containing the route to downstream neighbors and a flash 902 poison update containing the route should be sent upstream 903 indicating a change in downstream dependency (even if its on 904 the same upstream interface). 906 2. Received Metric = infinity 907 If the neighbor was considered to be the designated 908 forwarder, the receiving router should now become the 909 designated forwarder for the source network on this 910 interface. 912 a. Next hop = existing next hop 914 If the existing metric was less than infinity, the route is 915 now unreachable. Delete the route and schedule a flash 916 update containing the route to all interfaces for which you 917 are the designated forwarder or have downstream dependents. 919 b. Next hop != existing next hop 921 The route can be ignored since the existing next hop has a 922 metric better than or equal to this next hop. 924 If the neighbor was considered a downstream dependent 925 neighbor, this should be canceled. 927 3. infinity < Received Metric < 2 x infinity 929 The neighbor considers the receiving router to be upstream for 930 the route and is indicating it is dependent on the receiving 931 router. 933 If the neighbor was considered to be the designated forwarder, 934 the receiving router should now become the designated forwarder 935 for the source network on this interface. 937 a. Neighbor on downstream interface 939 If the sending neighbor is considered to be on a downstream 940 interface for that route then the neighbor is to be 941 registered as a downstream dependent router for that route. 943 If this is the first time the neighbor has indicated 944 downstream dependence for this source and one or more prunes 945 have been sent upstream containing this source network, then 946 Graft messages MUST be sent upstream in the direction of the 947 source network for each group with existing prune state. 949 b. Neighbor on upstream interface 951 If the receiving router thinks the neighbor is on the 952 upstream interface, then the route should be treated as if 953 an infinity metric was received (See Received Metric = 954 infinity). 956 4. 2 x infinity <= Received Metric 958 If the Received Metric is greater than or equal to 2 x 959 infinity, the Metric is illegal and the route should be 960 ignored. 962 3.4.7. Route Expiration 964 A route expires if it has not been refreshed within the Route 965 Expiration time. This should be set to 2 x Route Report Interval + 20 966 (or 140) seconds. Due to flash updates, routes will typically not 967 expire but instead be removed in response to receiving an infinity 968 metric for the route. However, since not all existing 969 implementations implement flash updates, route expiration is 970 necessary. 972 3.4.8. Route Hold-down 974 When a route is deleted (because it expires, the neighbor it was 975 learned from goes away, or an infinity metric is received for the 976 route) a router may be able to reach the source network described by 977 the route through an alternate gateway. However, in the presence of 978 complex topologies, often, the alternate gateway may only be echoing 979 back the same route learned via a different path. If this occurs, the 980 route will continue to be propagated long after it is no longer 981 valid. 983 In order to prevent this, it is common in distance vector protocols 984 to continue to advertise a route that has been deleted with a metric 985 of infinity for one or more report intervals. This is called Hold- 986 down. A route MUST only be advertised with an infinity metric while 987 it is in hold-down. The hold-down period is 2 Report Intervals. 989 When a route goes into hold-down, all forwarding cache entries based 990 on the route should be flushed. 992 During the hold-down period, the route may be learned via a different 993 gateway or the same gateway with a different metric. The router MAY 994 use this new route for delivering to local group members. Also, 995 installing a new route during the hold-down period allows the route 996 to be advertised with a non-infinity metric more quickly once the 997 hold-down period is over. 999 In order to minimize outages caused by flapping routes, it is 1000 permissible to prematurely take a route out of hold-down ONLY if the 1001 route is re-learned from the SAME router with the SAME metric. 1003 Route hold-down is not effective if only some routers implement it. 1004 Therefore, it is now a REQUIRED part of the protocol. 1006 3.4.9. Graceful Shutdown 1008 During a graceful shutdown, an implementation MAY want to inform 1009 neighbor routers that it is terminating. Routes that have been 1010 advertised with a metric less than infinity should now be advertised 1011 with a metric equal to infinity. This will allow neighbor routers to 1012 switch more quickly to an alternate path for a source network if one 1013 exists. 1015 Routes that have been advertised with a metric between infinity and 2 1016 x infinity (indicating downstream neighbor dependence) should now be 1017 advertised with a metric equal to infinity (canceling the downstream 1018 dependence). 1020 3.4.10. Route Report Packet Format 1022 The format of a sample Route Report Packet is shown in Figure 4 1023 below. The packet shown is an example of how the source networks are 1024 packed into a Report. The number of octets in each Source Network 1025 will vary depending on the mask value. The values below are only an 1026 example for clarity and are not intended to represent the format of 1027 every Route Report. 1029 7 15 23 31 1030 +-----------+------------+-------------------------+ 1031 | Type | Code | Checksum | 1032 | (0x13) | (0x2) | | 1033 +-----------+------------+------------+------------+ 1034 | Reserved | Minor | Major | 1035 | | Version | Version | 1036 +-----------+------------+------------+------------+ 1037 | Mask1 | Mask1 | Mask1 | Src | 1038 | Octet2 | Octet3 | Octet4 | Net11 | 1039 +-----------+------------+------------+------------+ 1040 | SrcNet11(cont.)... | Metric11 | Src | 1041 | | | Net12 | 1042 +------------------------+------------+------------+ 1043 | SrcNet12(cont.)... | Metric12 | Mask2 | 1044 | | | Octet2 | 1045 +-----------+------------+------------+------------+ 1046 | Mask2 | Mask2 | SrcNet21 | 1047 | Octet3 | Octet4 | | 1048 +-----------+------------+------------+------------+ 1049 | SrcNet21(cont.)... | Metric21 | Mask3 | 1050 | | | Octet2 | 1051 +-----------+------------+------------+------------+ 1052 | Mask3 | Mask3 | ... | 1053 | Octet3 | Octet4 | | 1054 +-----------+------------+-------------------------+ 1056 Figure 4 - Example Route Report Packet Format 1058 3.5. Pruning 1060 DVMRP is described as a broadcast and prune multicast routing 1061 protocol since datagrams are initially sent out all dependent 1062 downstream interfaces forming a tree rooted at the source of the 1063 data. As the routers at the leaves of the tree begin to receive 1064 unwanted multicast traffic, they send prune messages upstream toward 1065 the source. This results in the multicast tree for a given source 1066 network and a given set of receivers. 1068 3.5.1. Leaf Networks 1070 Detection of leaf networks is very important to the pruning process. 1071 Routers at the end of a source specific multicast delivery tree must 1072 detect that there are no further downstream dependent routers. This 1073 detection mechanism is covered above in section 3.2 titled Probe 1074 Messages. If there are no group members present for a particular 1075 multicast datagram received, the leaf routers will start the pruning 1076 process by removing their downstream interfaces and sending a prune 1077 to the upstream router for that source. 1079 3.5.2. Source Networks 1081 By default, prunes are meant to be applied to a group and source 1082 network. However, it is possible to include a Netmask in the Prune 1083 message to alter this behavior. If no Netmask is included, a prune 1084 sent upstream triggered by traffic received from a particular source 1085 applies to all sources on that network. If a Netmask is included, it 1086 MUST first be validated. If the Netmask is a host mask, only that 1087 source address should be pruned. Otherwise, the Netmask MUST match 1088 the mask sent to the downstream router for that source. If it does 1089 not match the mask that the upstream router expected, the upstream 1090 router MUST ignore the prune and should log an error. When a 1091 aggregate source network is advertised downstream, the Netmask in the 1092 prune will match the mask of the aggregate route that was advertised. 1094 If the Prune message only contains the host address of the source 1095 (and not the corresponding Netmask), the source network can be 1096 determined easily by a best-match lookup using the routing table 1097 distributed as a part of DVMRP. 1099 3.5.3. Receiving a Prune 1101 When a prune is received, the following steps should be taken: 1103 1. If the neighbor is unknown, discard the received prune. 1105 2. Ensure the prune message contains at least the correct amount of 1106 data. 1108 3. Copy the source address, group address, and prune time-out value. 1109 If it is available in the packet, copy the Netmask value. 1110 Determine route to which prune applies. 1112 4. If there is no active source information for the (source network, 1113 group) pair, then ignore the prune. 1115 5. Verify that the prune was received from a dependent neighbor for 1116 the source network. If not, discard the prune. 1118 6. Determine if a prune is currently active from the same dependent 1119 neighbor for this (source network, group) pair. 1121 7. If so, reset the timer to the new time-out value. Otherwise, 1122 create state for the new prune and set a timer for the prune 1123 lifetime. 1125 8. Determine if all dependent downstream routers on the interface 1126 from which the prune was received have now sent prunes. 1128 9. If so, then determine if there are group members active on the 1129 interface and if this router is the designated forwarder for the 1130 network. 1132 10. If not, then remove the interface from all forwarding cache 1133 entries for this group instantiated using the route to which the 1134 prune applies. 1136 3.5.4. Sending a Prune 1138 When a forwarding cache is being used, there is a trade-off that should 1139 be considered when deciding when Prune messages should be sent upstream. 1140 In all cases, when a data packet arrives and the downstream interface 1141 list is empty, a prune is sent upstream. However, when a forwarding 1142 cache entry transistions to an empty downstream interface list it is 1143 possible as an optimization to send a prune at this time as well. This 1144 prune will possibly stop unwanted traffic sooner at the expense of 1145 sending extra prune traffic for sources that are no longer sending. 1146 When sending a prune upstream, the following steps should be taken: 1148 1. Decide if upstream neighbor is capable of receiving prunes. 1150 2. If not, then proceed no further. 1152 3. Stop any pending Grafts awaiting acknowledgments. 1154 4. Determine the prune lifetime. This value should be the minimum of 1155 the default prune lifetime (randomized to prevent synchronization) 1156 and the remaining prune lifetimes of the downstream neighbors. 1158 5. Form and transmit the packet to the upstream neighbor for the 1159 source. 1161 3.5.5. Retransmitting a Prune 1163 By increasing the prune lifetime to ~2 hours, the effect of a lost 1164 prune message becomes more apparent. Therefore, an implementation 1165 SHOULD retransmit prunes messages using binary exponential back-off 1166 during the lifetime of the prune if traffic is still arriving on the 1167 upstream interface. 1169 One way to implement this would be to send a prune, install a 1170 negative cache entry for 3 seconds while waiting for the prune to 1171 take effect. Then remove the negative cache entry. If traffic 1172 continues to arrive, a new forwarding cache request will be 1173 generated. The prune can be resent with the remaining prune lifetime 1174 and a negative cache entry can be installed for 6 seconds. After 1175 this, the negative cache entry is removed. This procedure is repeated 1176 while each time doubling the length of time the negative cache entry 1177 is installed. 1179 In addition to using binary exponential back-off, the interval 1180 between subsequent retransmissions should also be randomized to 1181 prevent synchronization. 1183 On multi-access networks, even if a prune is received by the upstream 1184 router, data may still be received due to other receivers (i.e. group 1185 members or other downstream dependent routers) on the network. 1187 3.5.6. Prune Packet Format 1189 A Prune Packet contains three required fields: the source host IP 1190 address, the destination group IP address, and the Prune Lifetime in 1191 seconds. An optional source network mask may also be appended to the 1192 Prune message. This mask applied to the Source Host Address will 1193 indicate the route that the prune applies to. A Source Network Mask 1194 field should only be sent in a Prune message to a neighbor if that 1195 neighbor has advertised the ability to process it by setting the 1196 Netmask capabilities bit. The length of the Prune message will 1197 indicate if the Source Network Mask has been included or not. 1199 The Prune Lifetime is a derived value calculated as the minimum of 1200 the default prune lifetime (2 hours) and the remaining lifetimes of 1201 any downstream prunes received for this source network and group. A 1202 router with no downstream dependent neighbors would use the the 1203 default prune lifetime (randomized to prevent synchronization). 1205 7 15 23 31 1206 +-----------+------------+-------------------------+ 1207 | Type | Code | Checksum | 1208 | (0x13) | (0x7) | | 1209 +-----------+------------+------------+------------+ 1210 | Reserved | Minor | Major | 1211 +------------------------+------------+------------+ 1212 | Source Host Address | 1213 +--------------------------------------------------+ 1214 | Group Address | 1215 +--------------------------------------------------+ 1216 | Prune Lifetime | 1217 +--------------------------------------------------+ 1218 | Source Network Mask | 1219 +--------------------------------------------------+ 1221 Figure 5 - Prune Packet Format 1223 Source Host Address 1224 The source host IP address of the datagram that triggered the 1225 prune. 1227 Group Address 1228 The destination group IP address of the datagram that triggered 1229 the prune. 1231 Prune Lifetime 1232 The number of seconds for which the upstream neighbor should keep 1233 this prune active. 1235 Source Network Mask 1236 The (optional) netmask of the route this prune applies to. 1238 3.6. Grafting 1240 Once a multicast delivery tree has been pruned back, DVMRP Graft 1241 messages are necessary to join new receivers onto the multicast tree. 1242 Graft messages are sent upstream hop-by-hop from the new receiver's 1243 first-hop router until a point on the multicast tree is reached. 1244 Since there is no way to tell whether a graft message was lost or the 1245 source stopped sending, each Graft message is acknowledged hop by 1246 hop. This ensures that the Graft message is not lost somewhere along 1247 the path between the receiver's first-hop router and the closest 1248 point on the multicast delivery tree. 1250 One or more Graft messages should be sent under the following 1251 conditions: 1253 1. A new local member joins a group that has been pruned upstream and 1254 this router is the designated forwarder for the source. 1256 2. A new dependent downstream router appears on a pruned branch. 1258 3. A dependent downstream router on a pruned branch restarts (new 1259 Generation ID). 1261 4. A Graft Retransmission Timer expires before a Graft-Ack is 1262 received. 1264 3.6.1. Sending a Graft 1266 Recall that by default, Prunes are source network specific and are 1267 sent up different trees for each source network. Grafts are sent in 1268 response to various conditions which are not necessarily source 1269 specific. Therefore, it may be necessary to send separate Graft 1270 messages to the appropriate upstream routers to counteract each 1271 previous source network specific prune that was sent. 1273 As mentioned above, a Graft message sent to the upstream DVMRP router 1274 should be acknowledged hop by hop guaranteeing end-to-end delivery. 1275 In order to send a Graft message, the following steps should be 1276 taken: 1278 1. Verify a prune exists for the source network and group. 1280 2. Verify that the upstream router is capable of receiving prunes 1281 (and therefore grafts). 1283 3. Add the graft to the retransmission timer list awaiting an 1284 acknowledgment. 1286 4. Formulate and transmit the Graft packet. 1288 If a Graft Acknowledgment is not received within the Graft 1289 Retransmission Time-out period, the Graft should be resent to the 1290 upstream router. The initial retransmission period is 5 seconds. A 1291 binary exponential back-off policy is used on subsequent 1292 retransmissions. 1294 3.6.2. Receiving a Graft 1296 1. If the neighbor is unknown, discard the received graft. 1298 2. Ensure the graft message contains at least the correct amount of 1299 data. 1301 3. Send back a Graft Ack to the sender. 1303 4. If the sender was a downstream dependent neighbor from which a 1304 prune had previously been received, then remove the prune state 1305 for this neighbor. If necessary, any forwarding cache entries 1306 based on this (source, group) pair should be updated to include 1307 this downstream interface. 1309 5. If a prune had been sent upstream, this may trigger a graft to 1310 now be sent to the upstream router. 1312 3.6.3. Graft Packet Format 1314 The format of a Graft packet is show below: 1316 7 15 23 31 1317 +-----------+------------+-------------------------+ 1318 | Type | Code | Checksum | 1319 | (0x13) | (0x8) | | 1320 +-----------+------------+------------+------------+ 1321 | Reserved | Minor | Major | 1322 +------------------------+------------+------------+ 1323 | Source Host Address | 1324 +--------------------------------------------------+ 1325 | Group Address | 1326 +--------------------------------------------------+ 1327 | Source Network Mask | 1328 +--------------------------------------------------+ 1330 Figure 6 - Graft Packet Format 1332 Source Host Address 1333 The source host IP address indicating which source host or source 1334 network to Graft. 1336 Group Address 1337 The destination group IP address to be grafted. 1339 Source Network Mask 1340 The (optional) netmask of the route this graft applies to. 1342 3.6.4. Sending a Graft Acknowledgment 1344 A Graft Acknowledgment packet is sent to a downstream neighbor in 1345 response to receiving a Graft message. All Graft messages MUST be 1346 acknowledged. This is true even if no other action is taken in 1347 response to receiving the Graft to prevent the source from 1348 continually re-transmitting the Graft message. The Graft 1349 Acknowledgment packet is identical to the Graft packet except that 1350 the DVMRP code in the common header is set to Graft Ack. This allows 1351 the receiver of the Graft Ack message to correctly identify which 1352 Graft was acknowledged and stop the appropriate retransmission timer. 1354 3.6.5. Receiving a Graft Acknowledgment 1356 When a Graft Acknowledgment is received, ensure the message contains 1357 at least the correct amount of data. The (source address, group) 1358 pair in the packet can be used to determine if a Graft was sent to 1359 this particular upstream router. If no Graft was sent, the Graft Ack 1360 can simply be ignored. If a Graft was sent, and the acknowledgment 1361 has come from the correct upstream router, then it has been 1362 successfully received and the retransmission timer for the Graft can 1363 be stopped. 1365 3.6.6. Graft Acknowledgment Packet Format 1367 The format of a Graft Ack packet (which is identical to that of a 1368 Graft packet) is show below: 1370 7 15 23 31 1371 +-----------+------------+-------------------------+ 1372 | Type | Code | Checksum | 1373 | (0x13) | (0x9) | | 1374 +-----------+------------+------------+------------+ 1375 | Reserved | Minor | Major | 1376 +------------------------+------------+------------+ 1377 | Source Host Address | 1378 +--------------------------------------------------+ 1379 | Group Address | 1380 +--------------------------------------------------+ 1381 | Source Network Mask | 1382 +--------------------------------------------------+ 1384 Figure 7 - Graft Ack Packet Format 1386 Source Host Address 1387 The source host IP address that was received in the Graft message. 1389 Group Address 1390 The destination group IP address that was received in the Graft 1391 message. 1393 Source Network Mask 1394 The (optional) netmask of the route this Graft Ack applies to. 1396 3.7. Interfaces 1398 Interfaces running DVMRP will either be multicast capable physical 1399 interfaces or encapsulated tunnel pseudo-interfaces. Physical 1400 interfaces may either be multi-access networks or point-to-point 1401 networks. Tunnel interfaces are used when there are non-multicast 1402 capable routers between DVMRP neighbors. Protocol messages and 1403 multicast data traffic are sent between tunnel endpoints using a 1404 standard encapsulation method [Perk96,Han94a,Han94b]. The unicast IP 1405 addresses of the tunnel endpoints are used as the source and 1406 destination IP addresses in the outer IP header. The inner IP header 1407 remains unchanged from the original packet. 1409 Protocol messages on point-to-point links should always use a 1410 destination IP address of All-DVMRP-Routers for ALL message types. 1411 While Prune, Graft, and Graft-Ack messages are only intended for a 1412 single recipient, the use of a multicast destination address is 1413 necessary for un-numbered links and encapsulated interfaces. 1415 When multiple addresses are configured on a single interface, it is 1416 necessary that all routers on the interface know about the same set 1417 of network addresses. In this way, each router will make the same 1418 choice for the designated forwarder for each source. In addition, a 1419 router configured with multiple addresses on an interface should 1420 consistently use the same address when sending DVMRP control 1421 messages. 1423 The maximum packet length of any DVMRP message should be the maximum 1424 packet size required to be forwarded without fragmenting. The use of 1425 Path MTU Discovery [Mogu90] is encouraged to determine this size. In 1426 the absence of Path MTU, the Requirements for Internet Hosts [Brad89] 1427 specifies this number as 576 octets. Be sure to consider the size of 1428 the encapsulated IP header as well when calculating the maximum size 1429 of a DVMRP protocol message. 1431 3.7.1. Interface transitions 1433 When an interface transitions to the up state, the generation ID of 1434 that interface should be updated so that DVMRP neighbors know to 1435 resend prune information. 1437 When an interface transitions to the down state, all neighbors on 1438 that interface should be expired. All actions associated with an 1439 expired neighbor should be taken as specified in the Neighbor Expiry 1440 section. 1442 4. IANA Considerations 1444 The Internet Assigned Numbers Authority (IANA) is the central 1445 coordinator for the assignment of unique parameter values for 1446 Internet protocols. DVMRP uses IGMP [Fenn97] IP protocol messages to 1447 communicate between routers. The IGMP Type field is hexadecimal 0x13. 1449 On IP multicast capable networks, DVMRP uses the All-DVMRP-Routers 1450 local multicast group. This group address is 224.0.0.4. 1452 5. Network Management Considerations 1454 DVMRP provides several methods for network management monitoring and 1455 troubleshooting. Appendix B describes a request/response mechanism to 1456 directly query DVMRP neighbor information. In addition, a Management 1457 Information Base for DVMRP is defined in [Thal97]. 1459 A Management Information Base for the multicast forwarding cache is 1460 defined in [McCl00]. 1462 Also, a protocol independent multicast trace-route facility is 1463 defined in [Fenn00]. 1465 6. Security Considerations 1467 Security for DVMRP follows the general security architecture provided 1468 for the Internet Protocol [Ken98a]. This framework provides for both 1469 privacy and authentication. It recommends the use of the IP 1470 Authentication Header [Ken98b] to provide trusted neighbor 1471 relationships. Confidentiality is provided by the addition of the IP 1472 Encapsulating Security Payload [Ken98c]. 1474 7. References 1476 [Brad88] Braden, R., Borman, D., Partridge, C., "Computing the 1477 Internet Checksum", RFC 1071, September 1988. 1479 [Brad89] Braden, R., "Requirements for Internet Hosts -- 1480 Communication Layers", RFC 1122, October 1989. 1482 [Deer89] Deering, S., "Host Extensions for IP Multicasting", RFC 1483 1112, August 1989. 1485 [Deer90] Deering, S., Cheriton, D., "Multicast Routing in Datagram 1486 Internetworks and Extended LANs", ACM Transactions on 1487 Computer Systems, Vol. 8, No. 2, May 1990, pp. 85-110. 1489 [Deer91] Deering, S., "Multicast Routing in a Datagram 1490 Internetwork", PhD thesis, Electric Engineering Dept., 1491 Stanford University, December 1991. 1493 [Fenn97] Fenner, W., "Internet Group Management Protocol, Version 1494 2", RFC 2236, November 1997. 1496 [Fenn00] Fenner, W., Casner, S., "A "traceroute" facility for IP 1497 Multicast", Work In Progress, July 2000. 1499 [Full93] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 1500 Inter-Domain Routing (CIDR): an Address Assignment and 1501 Aggregation Strategy", RFC 1519, September 1993. 1503 [Han94a] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic 1504 Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and 1505 cisco Systems, October 1994. 1507 [Han94b] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1508 Routing Encapsulation over IPv4 networks", RFC 1702, 1509 NetSmiths, Ltd., cisco Systems, October 1994. 1511 [Ken98a] Kent, S., Atkinson, R. "Security Architecture for the 1512 Internet Protocol", RFC 2401, November 1998. 1514 [Ken98b] Kent, S., Atkinson, R., "IP Authentication Header", RFC 1515 2402, November 1998. 1517 [Ken98c] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 1518 (ESP)", RFC 2406, November 1998. 1520 [McCl00] McCloghrie, K., Farinacci, D., Thaler, D., "IP Multicast 1521 Routing MIB", Work In Progress, July 2000. 1523 [Mogu90] Mogul, J., Deering, S., "Path MTU Discovery", RFC 1191, 1524 November 1990. 1526 [Perk96] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1527 October 1996. 1529 [Perl92] Perlman, R., "Interconnections: Bridges and Routers", 1530 Addison-Wesley, May 1992, pp. 205-211. 1532 [Post81] Postel, J., "Internet Protocol", RFC 791, September, 1981. 1534 [Rekh93] Rekhter, Y., and T. Li, "An Architecture for IP Address 1535 Allocation with CIDR", RFC 1518, September 1993. 1537 [Reyn94] Reynolds, J., Postel, J., "Assigned Numbers", STD 0002, 1538 October 1994. 1540 [Thal97] Thaler, D., "Distance-Vector Multicast Routing Protocol 1541 MIB", Work In Progress, April 1997. 1543 [Wait88] Waitzman, D., Partridge, C., Deering, S., "Distance Vector 1544 Multicast Routing Protocol", RFC 1075, November 1988. 1546 8. Author's Address 1548 Thomas Pusateri 1549 Juniper Networks, Inc. 1550 1194 North Mathilda Avenue 1551 Sunnyvale, CA 94089 USA 1552 Phone: (408) 734-7690 1553 EMail: pusateri@juniper.net 1555 9. Acknowledgments 1557 The author would like to acknowledge the original designers of the 1558 protocol, Steve Deering, Craig Partridge, and David Waitzman. 1559 Version 3 of the protocol would not have been possible without the 1560 original work of Ajit Thyagarajan and the ongoing (and seemingly 1561 endless) work of Bill Fenner. Credit also goes to Danny Mitzel and 1562 Dave Thaler for the careful review of this document and Nitin Jain, 1563 Dave LeRoy, Charles Mumford, Ravi Shekhar, and Shuching Shieh for 1564 their helpful comments. 1566 10. Appendix A - Constants & Configurable Parameters 1568 The following table provides a summary of the DVMRP timing 1569 parameters: 1571 Parameter Value (seconds) 1572 ---------------------------------------------------------- 1573 Probe Interval 10 1574 Neighbor Time-out Interval 35 1575 Minimum Flash Update Interval 5 1576 Route Report Interval 60 1577 Route Expiration Time 140 1578 Route Hold-down 2 x Route Report Interval 1579 Prune Lifetime variable (< 2 hours) 1580 Prune Retransmission Time 3 with exp. back-off 1581 Graft Retransmission Time 5 with exp. back-off 1582 ---------------------------------------------------------- 1584 Table 2 - Parameter Summary 1586 11. Appendix B - Tracing and Troubleshooting support 1588 There are several packet types used to gather DVMRP specific 1589 information. They are generally used for diagnosing problems or 1590 gathering topology information. The first two messages are now 1591 obsoleted and should not be used. The remaining two messages provide 1592 a request/response mechanism to determine the versions and 1593 capabilities of a particular DVMRP router. 1595 Code Packet Type Description 1596 ----------------------------------------------------------- 1597 3 DVMRP Ask Neighbors Obsolete 1598 4 DVMRP Neighbors Obsolete 1599 5 DVMRP Ask Neighbors 2 Request Neighbor List 1600 6 DVMRP Neighbors 2 Respond with Neighbor List 1601 ----------------------------------------------------------- 1603 Table 3 - Debugging Packet Types 1605 11.1. DVMRP Ask Neighbors2 1607 The Ask Neighbors2 packet is a unicast request packet directed at a 1608 DVMRP router. The destination should respond with a unicast 1609 Neighbors2 message back to the sender of the Ask Neighbors2 message. 1611 0 8 16 31 1612 +---------+---------+--------------------+ 1613 | Type | Code | Checksum | 1614 |(0x13) | (0x5) | | 1615 +---------+---------+----------+---------+ 1616 | Reserved | Minor | Major | 1617 | | Version |Version | 1618 +-------------------+----------+---------+ 1620 Figure 8 - Ask Neighbors 2 Packet Format 1622 11.2. DVMRP Neighbors2 1624 The format of a Neighbors2 response packet is shown below. This is 1625 sent as a unicast message back to the sender of an Ask Neighbors2 1626 message. There is a common header at the top followed by the routers 1627 capabilities. One or more sections follow that contain an entry for 1628 each logical interface. The interface parameters are listed along 1629 with a variable list of neighbors learned on each interface. 1631 If the interface is down or disabled, list a single neighbor with an 1632 address of 0.0.0.0 for physical interfaces or the remote tunnel 1633 endpoint address for tunnel pseudo-interfaces. 1635 0 8 16 31 1636 +-----------+--------------+--------------------------+ 1637 | Type | Code | Checksum | 1638 | (0x13) | (0x6) | | 1639 +-----------+--------------+------------+-------------+ 1640 | Reserved | Capabilities | Minor | Major | 1641 | | | Version | Version | 1642 +-----------+--------------+------------+-------------+ 1643 | | 1644 | Local Addr 1 | 1645 +-----------+--------------+------------+-------------+ 1646 | | | | | 1647 | Metric 1 | Threshold 1 | Flags 1 | Nbr Count 1 | 1648 +-----------+--------------+------------+-------------+ 1649 | | 1650 | Nbr 1 | 1651 +-----------------------------------------------------+ 1652 | | 1653 | ... | 1654 +-----------------------------------------------------+ 1655 | | 1656 | Nbr m | 1657 +-----------------------------------------------------+ 1658 | | 1659 | Local Addr N | 1660 +-----------+--------------+------------+-------------+ 1661 | | | | | 1662 | Metric N | Threshold N | Flags N | Nbr Count N | 1663 +-----------+--------------+------------+-------------+ 1664 | | 1665 | Nbr 1 | 1666 +-----------------------------------------------------+ 1667 | | 1668 | ... | 1669 +-----------------------------------------------------+ 1670 | | 1671 | Nbr k | 1672 +-----------------------------------------------------+ 1674 Figure 9 - Neighbors 2 Packet Format 1676 The capabilities of the local router are defined as follows: 1678 Bit Flag Description 1679 --------------------------------------------------- 1681 0 Leaf This is a leaf router 1683 1 Prune This router understands pruning 1685 2 GenID This router sends Generation Id's 1687 3 Mtrace This router handles Mtrace requests 1689 4 Snmp This router supports the DVMRP MIB 1690 --------------------------------------------------- 1692 Table 4 - DVMRP Router Capabilities 1694 The flags associated with a particular interface are: 1696 Bit Flag Description 1697 ---------------------------------------------------------- 1699 0 Tunnel Neighbor reached via tunnel 1701 1 Source Route Tunnel uses IP source routing 1703 2 Reserved No longer used 1705 3 Reserved No longer used 1707 4 Down Operational status down 1709 5 Disabled Administrative status down 1711 6 Querier Querier for interface 1713 7 Leaf No downstream neighbors on interface 1714 ---------------------------------------------------------- 1716 Table 5 - DVMRP Interface flags 1718 12. Appendix C - Version Compatibility 1720 There have been two previous major versions of DVMRP with 1721 implementations still in circulation. If the receipt of a Probe 1722 message reveals a major version of 1 or 2, then it can be assumed 1723 that this neighbor does not support pruning or the use of the 1724 Generation ID in the Probe message. However, since these older 1725 implementations are known to safely ignore the Generation ID and 1726 neighbor information in the Probe packet, it is not necessary to send 1727 specially formatted Probe packets to these neighbors. 1729 There were three minor versions (0, 1, and 2) of major version 3 that 1730 did support pruning but did not support the Generation ID or 1731 capability flags. These special cases will have to be accounted for. 1733 Any other minor versions of major version 3 closely compare to this 1734 specification. 1736 In addition, cisco Systems is known to use their software major and 1737 minor release number as the DVMRP major and minor version number. 1738 These will typically be 10 or 11 for the major version number. 1739 Pruning was introduced in Version 11. 1741 Implementations prior to this specification may not wait to send 1742 route reports until probe messages have been received with the 1743 routers address listed. Reports SHOULD be sent to these neighbors 1744 without first requiring a received probe with the routers address in 1745 it as well as reports from these neighbors SHOULD be accepted. 1746 Although, this allows one-way neighbor relationships to occur, it 1747 does maintain backward compatibility. 1749 It may be necessary to form neighbor relationships based solely on 1750 Route Report messages. Neighbor time-out values may need to be 1751 configured to a value greater than the Route Report Interval for 1752 these neighbors. 1754 Implementations that do not monitor Generation ID changes can create 1755 more noticeable black holes when using long prune lifetimes such as 1756 ~2 hours. This happens when a long prune is sent upstream and then 1757 the router that sent the long prune restarts. If the upstream router 1758 ignores the new Generation ID, the prune received by the upstream 1759 router will not be flushed and the downstream router will have no 1760 knowledge of the upstream prune. For this reason, prunes sent 1761 upstream to routers that are known to ignore Generation ID changes 1762 should have short lifetimes. 1764 If the router must run IGMP version 1 on an interface for backwards 1765 compatibility, DVMRP must elect the DVMRP router with the highest IP 1766 address as the IGMP querier. 1768 Some implementations of tools that send DVMRP Ask Neighbors2 requests 1769 and receive Neighbors2 response messages require a neighbor address 1770 of 0.0.0.0 when no neighbors are listed in the response packet. 1771 (Mrinfo) 1773 When DVMRP protocol packets are sent to tunnel endpoints, some 1774 implementations do not accept packets addressed to the All-DVMRP- 1775 Routers address and then encapsulated with the tunnel endpoint 1776 address. Mrouted versions 3.9beta2 and earlier are known to have 1777 this problem. 1779 13. Intellectual Property Rights Notice 1781 The IETF takes no position regarding the validity or scope of any 1782 intellectual property or other rights that might be claimed to 1783 pertain to the implementation or use of the technology described in 1784 this document or the extent to which any license under such rights 1785 might or might not be available; neither does it represent that it 1786 has made any effort to identify any such rights. Information on the 1787 IETF's procedures with respect to rights in standards-track and 1788 standards-related documentation can be found in BCP-11. Copies of 1789 claims of rights made available for publication and any assurances of 1790 licenses to be made available, or the result of an attempt made to 1791 obtain a general license or permission for the use of such 1792 proprietary rights by implementors or users of this specification can 1793 be obtained from the IETF Secretariat. 1795 The IETF invites any interested party to bring to its attention any 1796 copyrights, patents or patent applications, or other proprietary 1797 rights which may cover technology that may be required to practice 1798 this standard. Please address the information to the IETF Executive 1799 Director. 1801 14. Full Copyright Statement 1803 Copyright (C) The Internet Society (date). All Rights Reserved. 1805 This document and translations of it may be copied and furnished to 1806 others, and derivative works that comment on or otherwise explain it 1807 or assist in its implmentation may be prepared, copied, published and 1808 distributed, in whole or in part, without restriction of any kind, 1809 provided that the above copyright notice and this paragraph are 1810 included on all such copies and derivative works. However, this 1811 document itself may not be modified in any way, such as by removing 1812 the copyright notice or references to the Internet Society or other 1813 Internet organizations, except as needed for the purpose of 1814 developing Internet standards in which case the procedures for 1815 copyrights defined in the Internet Standards process must be 1816 followed, or as required to translate it into languages other than 1817 English. 1819 The limited permissions granted above are perpetual and will not be 1820 revoked by the Internet Society or its successors or assigns. 1822 This document and the information contained herein is provided on an 1823 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1824 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1825 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1826 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1827 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1829 Table of Contents 1831 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1832 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . . 2 1833 1.2. Reverse Path Multicasting . . . . . . . . . . . . . . . . . 2 1834 1.3. Tunnel Encapsulation . . . . . . . . . . . . . . . . . . . . 2 1835 1.4. Document Overview . . . . . . . . . . . . . . . . . . . . . 3 1836 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 1837 2.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . 4 1838 2.2. Source Location . . . . . . . . . . . . . . . . . . . . . . 4 1839 2.3. Dependent Downstream Routers . . . . . . . . . . . . . . . . 5 1840 2.4. Designated Forwarder . . . . . . . . . . . . . . . . . . . . 6 1841 2.5. Building Multicast Trees . . . . . . . . . . . . . . . . . . 6 1842 2.6. Pruning Multicast Trees . . . . . . . . . . . . . . . . . . 7 1843 2.7. Grafting Multicast Trees . . . . . . . . . . . . . . . . . . 8 1844 3. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 8 1845 3.1. Protocol Header . . . . . . . . . . . . . . . . . . . . . . 8 1846 3.2. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . 10 1847 3.3. Multicast Forwarding . . . . . . . . . . . . . . . . . . . . 15 1848 3.4. Route Exchange . . . . . . . . . . . . . . . . . . . . . . . 16 1849 3.5. Pruning . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1850 3.6. Grafting . . . . . . . . . . . . . . . . . . . . . . . . . . 30 1851 3.7. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 34 1852 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 1853 5. Network Management Considerations . . . . . . . . . . . . . . 35 1854 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 1855 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 1856 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 37 1857 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 1858 10. Appendix A - Constants & Configurable Parameters . . . . . . 39 1859 11. Appendix B - Tracing and Troubleshooting support . . . . . . 40 1860 11.1. DVMRP Ask Neighbors2 . . . . . . . . . . . . . . . . . . . 40 1861 11.2. DVMRP Neighbors2 . . . . . . . . . . . . . . . . . . . . . 41 1862 12. Appendix C - Version Compatibility . . . . . . . . . . . . . 45 1863 13. Intellectual Property Rights Notice . . . . . . . . . . . . . 47 1864 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 47