idnits 2.17.1 draft-ietf-idmr-dvmrp-v3-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** 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 46: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 47: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 132: '... MUST be set to 1....' RFC 2119 keyword, line 373: '...e. The checksum MUST be calculated up...' RFC 2119 keyword, line 374: '...transmission and MUST be validated on ...' (30 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 331 has weird spacing: '...ets are encap...' == Line 364 has weird spacing: '...aft Ack for ...' -- 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 1998) is 9385 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 49, but not defined -- Looks like a reference, but probably isn't: '00' on line 753 ** 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. 'Fen97b' ** 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') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ken98a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ken98b' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ken98c' -- Possible downref: Non-RFC (?) normative reference: ref. 'McCl98' -- 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 (~~), 7 warnings (==), 14 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 1998 5 draft-ietf-idmr-dvmrp-v3-07 Expires: February 1999 7 Distance Vector Multicast Routing Protocol 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as `'work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 `'1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 DVMRP is an Internet routing protocol that provides an efficient 30 mechanism for connection-less datagram delivery to a group of hosts 31 across an internetwork. It is a distributed protocol that dynamically 32 generates IP Multicast delivery trees using a technique called 33 Reverse Path Multicasting (RPM) [Deer90]. This document is an update 34 to Version 1 of the protocol specified in RFC 1075 [Wait88]. 36 1. Introduction 38 DVMRP uses a distance vector distributed routing algorithm in order 39 to build per-source-group multicast delivery trees. A good 40 introduction to distance vector routing can be found in [Perl92]. 41 The application of distance vector routing to multicast tree 42 formulation is described in [Deer91]. 44 1.1. Requirements Terminology 46 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 47 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 48 document, are to be interpreted as described in [RFC-2119]. 50 1.2. Reverse Path Multicasting 52 Datagrams follow multicast delivery trees from a source to all 53 members of a multicast group [Deer89], replicating the packet only at 54 necessary branches in the delivery tree. The trees are calculated and 55 updated dynamically to track the membership of individual groups. 56 When a datagram arrives on an interface, the reverse path to the 57 source of the datagram is determined by examining a DVMRP routing 58 table of known source networks. If the datagram arrives on an 59 interface that would be used to transmit datagrams back to the 60 source, then it is forwarded to the appropriate list of downstream 61 interfaces. Otherwise, it is not on the optimal delivery tree and 62 should be discarded. In this way duplicate packets can be filtered 63 when loops exist in the network topology. The source specific 64 delivery trees are automatically pruned back as group membership 65 changes or leaf routers determine that no group members are present. 66 This keeps the delivery trees to the minimum branches necessary to 67 reach all of the group members. New sections of the tree can also be 68 added dynamically as new members join the multicast group by grafting 69 the new sections onto the delivery trees. 71 1.3. Tunnel Encapsulation 73 Because not all IP routers support native multicast routing, DVMRP 74 includes direct support for tunneling IP Multicast datagrams through 75 routers. The IP Multicast datagrams are encapsulated in unicast IP 76 packets and addressed to the routers that do support native multicast 77 routing. DVMRP treats tunnel interfaces in an identical manner to 78 physical network interfaces. 80 In previous implementations, DVMRP protocol messages were sent un- 81 encapsulated to the unicast tunnel endpoint address. While this was 82 more direct, it increased the complexity of firewall configuration. 83 The most noticeable change in this specification regarding tunnels is 84 that all DVMRP protocol messages should be sent encapsulated across 85 the tunnel. Previously, protocol messages were sent un-encapsulated 86 directly to the tunnel endpoint. See Appendix C for backward 87 compatibility issues. 89 Note: All protocol messages sent on point-to-point links (including 90 tunnels) should use a destination address of All-DVMRP-Routers. This 91 change will allow the protocol messages to be forwarded across 92 multicast-only tunnels without making encapsulation and decapsulation 93 difficult. 95 In practice, tunnels typically use either IP-IP [Perk96] or Generic 96 Routing Encapsulation (GRE) [Han94a,Han94b], although, other 97 encapsulation methods are acceptable. 99 1.4. Document Overview 101 Section 2 provides an overview of the protocol and the different 102 message types exchanged by DVMRP routers. Those who wish to gain a 103 general understanding of the protocol but are not interested in the 104 more precise details may wish to only read this section. Section 3 105 explains the detailed operation of the protocol to accommodate 106 developers needing to provide inter-operable implementations. 107 Included in Appendix A, is a summary of the DVMRP parameters. A 108 section on DVMRP support for tracing and troubleshooting is the topic 109 of Appendix B. Finally, a short DVMRP version compatibility section 110 is provided in Appendix C to assist with backward compatibility 111 issues. 113 2. Protocol Overview 115 DVMRP can be summarized as a "broadcast & prune" multicast routing 116 protocol. It builds per-source broadcast trees based upon routing 117 exchanges, then dynamically creates per-source-group multicast 118 delivery trees by pruning (removing branches from) the source's 119 truncated broadcast tree. It performs Reverse Path Forwarding checks 120 to determine when multicast traffic should be forwarded to downstream 121 interfaces. In this way, source-rooted shortest path trees can be 122 formed to reach all group members from each source network of 123 multicast traffic. 125 2.1. Neighbor Discovery 127 Neighbor DVMRP routers are discovered dynamically by sending Neighbor 128 Probe Messages on local multicast capable network interfaces and 129 tunnel pseudo interfaces. These messages are sent periodically to the 130 All-DVMRP-Routers [Reyn94] IP Multicast group address. (See Appendix 131 C for backwards compatibility issues.) The IP TTL of these messages 132 MUST be set to 1. 134 Each Neighbor Probe message contains the list of Neighbor DVMRP 135 routers for which Neighbor Probe messages have been received on that 136 interface. In this way, Neighbor DVMRP routers can ensure that they 137 are seen by each other. 139 Once you have received a Probe from a neighbor that contains your 140 address in the neighbor list, you have established a two-way neighbor 141 adjacency with this router. 143 2.2. Source Location 145 When an IP Multicast datagram is received by a router running DVMRP, 146 it first looks up the source network in the DVMRP routing table. The 147 interface on which the best route to the source of the datagram was 148 received is called the upstream (also called RPF) interface. If the 149 datagram arrived on the correct upstream interface, then it is a 150 candidate for forwarding to one or more downstream interfaces. If the 151 datagram did not arrive on the anticipated upstream interface, it is 152 discarded. This check is known as a reverse path forwarding check and 153 must be performed by all DVMRP routers. 155 In order to ensure that all DVMRP routers have a consistent view of 156 the path back to a source, a routing table is propagated to all DVMRP 157 routers as an integral part of the protocol. Each router advertises 158 the network number and mask of the interfaces it is directly 159 connected to as well as relaying the routes received from neighbor 160 routers. DVMRP requires an interface metric to be configured on all 161 physical and tunnel interfaces. When a route is received, the metric 162 of the interface over which the datagram was received must be added 163 to the metric of the route being advertised in the route report 164 message. This adjusted metric should be used when comparing metrics 165 to determine the best upstream neighbor. 167 Although there is certainly additional overhead associated with 168 propagating a separate DVMRP routing table, it does provide two nice 169 features. First, since all DVMRP routers are exchanging the same 170 routes, there are no inconsistencies between routers when determining 171 the upstream interface (aside from normal convergence issues related 172 to distance vector routing protocols). By placing the burden of 173 synchronization on the protocol as opposed to the network manager, 174 DVMRP reduces the risk of creating routing loops or black holes due 175 to disagreement between neighbor routers on the upstream interface. 177 Second, by propagating its own routing table, DVMRP makes it 178 convenient to have separate paths for unicast versus multicast 179 datagrams. Although, ideally, many network managers would prefer to 180 keep their unicast and multicast traffic aligned, tunneled multicast 181 topologies may prevent this causing the unicast and multicast paths 182 to diverge. Additionally, service providers may prefer to keep the 183 unicast and multicast traffic separate for routing policy reasons as 184 they experiment with IP multicast routing and begin to offer it as a 185 service. 187 2.3. Dependent Downstream Routers 189 In addition to providing a consistent view of source networks, the 190 exchange of routes in DVMRP provides one other important feature. 191 DVMRP uses the route exchange as a mechanism for upstream routers to 192 determine if any downstream routers depend on them for forwarding 193 from particular source networks. DVMRP accomplishes this by using a 194 technique called "Poison Reverse". If a downstream router selects an 195 upstream router as the best next hop to a particular source network, 196 this is indicated by echoing back the route on the upstream interface 197 with a metric equal to the original metric plus infinity. When the 198 upstream router receives the report and sees a metric that lies 199 between infinity and twice infinity, it can then add the downstream 200 router from which it received the report to a list of dependent 201 routers for this source. 203 This list of dependent routers per source network built by the 204 "Poison Reverse" technique will provide the foundation necessary to 205 determine when it is appropriate to prune back the IP source specific 206 multicast trees. 208 2.4. Designated Forwarder 210 When two or more multicast routers are connected to a multi-access 211 network, it could be possible for duplicate packets to be forwarded 212 on the network (one copy from each router). DVMRP prevents this 213 possibility by electing a forwarder for each source as a side effect 214 of its route exchange. When two routers on a multi-access network 215 exchange source networks, each of the routers will know the others 216 metric back to each source network. Therefore, of all the DVMRP 217 routers on a shared network, the router with the lowest metric to a 218 source network is responsible for forwarding data on to the shared 219 network. If two or more routers have an equally low metric, the 220 router with the lowest IP address becomes the designated forwarder 221 for the network. In this way, DVMRP does an implicit designated 222 forwarder election for each source network on each downstream 223 interface. 225 2.5. Building Multicast Trees 227 As previously mentioned, when an IP multicast datagram arrives, the 228 upstream interface is determined by looking up the interface on which 229 the best route to the source of the datagram was received. If the 230 upstream interface is correct, then a DVMRP router will forward the 231 datagram to a list of downstream interfaces. 233 2.5.1. Adding Leaf Networks 235 Initially, the DVMRP router must consider all of the remaining IP 236 multicast capable interfaces (including tunnels) on the router. If 237 the downstream interface under consideration is a leaf network (has 238 no dependent downstream neighbors for the source network), then the 239 IGMP local group database must be consulted. 241 The IGMP local group database is maintained by all IP multicast 242 routers on each physical, multicast capable network [Fen97a]. If the 243 destination group address is listed in the local group database, and 244 the router is the designated forwarder for the source, then the 245 interface is included in the list of downstream interfaces. If there 246 are no group members on the interface, then the interface is removed 247 from the outgoing interface list. 249 2.5.2. Adding Non-Leaf Networks 251 Initially, all non-leaf networks should be included in the downstream 252 interface list when a forwarding cache entry is first being created. 253 This allows all downstream routers to be aware of traffic destined 254 for a particular (source network, group) pair. The downstream routers 255 will then have the option to send prunes and grafts for this (source 256 network, group) pair as requirements change from their respective 257 downstream routers and local group members. 259 2.6. Pruning Multicast Trees 261 As mentioned above, routers at the edges with leaf networks will 262 remove their leaf interfaces that have no group members associated 263 with an IP multicast datagram. If a router removes all of its 264 downstream interfaces, it notifies the upstream router that it no 265 longer wants traffic destined for a particular (source network, 266 group) pair. This is accomplished by sending a DVMRP Prune message 267 upstream to the router it expects to forward datagrams from a 268 particular source. 270 Recall that a downstream router will inform an upstream router that 271 it depends on the upstream router to receive datagrams from 272 particular source networks by using the "Poison Reverse" technique 273 during the exchange of DVMRP routes. This method allows the upstream 274 router to build a list of downstream routers on each interface that 275 are dependent upon it for datagrams from a particular source network. 276 If the upstream router receives prune messages from each one of the 277 dependent downstream routers on an interface, then the upstream 278 router can in turn remove this interface from its downstream 279 interface list. If the upstream router is able to remove all of its 280 downstream interfaces in this way, it can then send a DVMRP Prune 281 message to its upstream router. This continues until the unneeded 282 branches are removed from the delivery tree. 284 In order to remove old prune state information for (source network, 285 group) pairs that are no longer active, it is necessary to limit the 286 life of a prune and periodically resume the broadcasting procedure. 287 The prune message contains a prune lifetime, indicating the length of 288 time that the prune should remain in effect. When the prune lifetime 289 expires, if the interface is still a non leaf, the interface is 290 joined back onto the multicast delivery tree. If unwanted multicast 291 datagrams continue to arrive, the prune mechanism will be re- 292 initiated and the cycle will continue. If all of the downstream 293 interfaces are removed from a multicast delivery tree causing a DVMRP 294 Prune message to be sent upstream, the lifetime of the prune sent 295 must be equal to the minimum of the remaining lifetimes of the 296 received prunes. 298 2.7. Grafting Multicast Trees 300 Once a tree branch has been pruned from a multicast delivery tree, 301 packets from the corresponding (source network, group) pair will no 302 longer be forwarded. However, since IP multicast supports dynamic 303 group membership, hosts may join a multicast group at any time. In 304 this case, DVMRP routers use Grafts to cancel the prunes that are in 305 place from the host back on to the multicast delivery tree. A router 306 will send a Graft message to its upstream neighbor if a group join 307 occurs for a group that the router has previously sent a prune. 308 Separate Graft messages must be sent to the appropriate upstream 309 neighbor for each source network that has been pruned. Since there 310 would be no way to tell if a Graft message sent upstream was lost or 311 the source simply quit sending traffic, it is necessary to 312 acknowledge each Graft message with a DVMRP Graft Ack message. If an 313 acknowledgment is not received within a Graft Time-out period, the 314 Graft message should be retransmitted using binary exponential back- 315 off between retransmissions. Duplicate Graft Ack messages should 316 simply be ignored. The purpose of the Graft Ack message is to simply 317 acknowledge the receipt of a Graft message. It does not imply that 318 any action was taken as a result of receiving the Graft message. 319 Therefore, all Graft messages received from a neighbor with whom a 320 two-way neighbor relationship has been formed should be acknowledged 321 whether or not they cause an action on the receiving router. 323 3. Detailed Protocol Operation 325 This section contains a detailed description of DVMRP. It covers 326 sending and receiving of DVMRP messages as well as the generation and 327 maintenance of IP Multicast forwarding cache entries. 329 3.1. Protocol Header 331 DVMRP packets are encapsulated in IP datagrams, with an IP protocol 332 number of 2 (IGMP) as specified in the Assigned Numbers RFC [Reyn94]. 333 All fields are transmitted in Network Byte Order. DVMRP packets use a 334 common protocol header that specifies the IGMP [Fen97a] Packet Type 335 as hexadecimal 0x13 (DVMRP). DVMRP protocol packets should be sent 336 with the Precedence field in the IP header set to Internetwork 337 Control (hexadecimal 0xc0 for the Type of Service Octet) [Post81]. A 338 diagram of the common protocol header follows: 340 0 8 16 31 341 +---------+---------+--------------------+ 342 | Type | Code | Checksum | 343 |(0x13) | | | 344 +---------+---------+----------+---------+ 345 | Reserved | Minor | Major | 346 | | Version |Version | 347 +-------------------+----------+---------+ 349 Figure 1 - Common Protocol Header 351 A Major Version of 3 and a Minor Version of 0xFF should be used to 352 indicate compliance with this specification. The value of the Code 353 field determines the DVMRP packet type. Currently, there are codes 354 allocated for DVMRP protocol message types as well as protocol 355 analysis and troubleshooting packets. The protocol message Codes 356 are: 358 Code Packet Type Description 359 ---------------------------------------------------------------- 360 1 DVMRP Probe for neighbor discovery 361 2 DVMRP Report for route exchange 362 7 DVMRP Prune for pruning multicast delivery trees 363 8 DVMRP Graft for grafting multicast delivery trees 364 9 DVMRP Graft Ack for acknowledging graft messages 365 ---------------------------------------------------------------- 367 Table 1 - Standard Protocol Packet Types 369 There are additional codes used for protocol analysis and 370 troubleshooting. These codes are discussed in Appendix B. 372 The Checksum is the 16-bit one's complement of the one's complement 373 sum of the DVMRP message. The checksum MUST be calculated upon 374 transmission and MUST be validated on reception of a packet. The 375 checksum of the DVMRP message should be calculated with the checksum 376 field set to zero. See [Brad88] for more information. 378 3.2. Probe Messages 380 When a DVMRP router is configured to run on an interface (physical or 381 tunnel), it multicasts DVMRP Probe packets to inform other DVMRP 382 routers that it is operational. Effectively, they serve three 383 purposes. 385 1. Probes provide a mechanism for DVMRP routers to locate each other. 386 DVMRP sends on each interface, a Probe Message containing the list 387 of the neighbors detected for that specific interface. If no 388 DVMRP neighbors are found, the network is considered to be a leaf 389 network. 391 2. Probes provide a way for DVMRP routers to determine the 392 capabilities of each other. This may be deduced from the major and 393 minor version numbers in the Probe packet or directly from the 394 capability flags. These flags were first introduced to allow 395 optional protocol features. This specification now mandates the 396 use of Generation Id's and pruning and, therefore, provides no 397 optional capabilities. Other capability flags were used for 398 tracing and troubleshooting and are no longer a part of the actual 399 protocol. 401 3. Probes provide a keep-alive function in order to quickly detect 402 neighbor loss. Probes sent on each multicast capable interface 403 configured for DVMRP SHOULD use an interval of 10 seconds. The 404 neighbor time-out interval SHOULD be set at 35 seconds. This 405 allows fairly early detection of a lost neighbor yet provides 406 tolerance for busy multicast routers. These values MUST be 407 coordinated between all DVMRP routers on a physical network 408 segment. 410 3.2.1. Router Capabilities 412 In the past, there have been many versions of DVMRP in use with a 413 wide range of capabilities. Practical considerations require a 414 current implementation to inter-operate with these older 415 implementations that don't formally specify their capabilities and 416 are not compliant with this specification. For instance, for major 417 versions less than 3, it can be assumed that the neighbor does not 418 support pruning. The formal capability flags were first introduced 419 in an well known implementation (Mrouted version 3.5) in an attempt 420 to take the guess work out which features are supported by a 421 neighbor. Many of these flags are no longer necessary since they are 422 now a required part of the protocol, however, special consideration 423 is necessary to not confuse older implementations that expect these 424 flags to be set. Appendix C was written to assist with these and 425 other backward compatibility issues. 427 Three of the flags were used for actual protocol operation. The 428 other two assigned flags were used for troubleshooting purposes which 429 should be documented in a separate specification. All of the bits 430 marked "U" in the Figure below are now unused. They may be defined in 431 the future and MUST be set to 0 on transmission and ignored on 432 reception. Bit position 0 is the LEAF bit which is a current research 433 topic. It MUST be set to 0 and ignored on reception. Bit positions 434 1, 2, and 3 MUST be set to 1 for backward compatibility. They were 435 used to specify the PRUNE, GENID, and MTRACE bits. The first two, 436 PRUNE and GENID, are now required features. The MTRACE bit must be 437 set so existing implementations will not assume this neighbor does 438 not support multicast trace-route [Fen97b]. However, since this bit 439 is now reserved and set to 1, newer implementations should not use 440 this bit in the Probe message to determine if multicast trace-route 441 is supported by a neighbor. Instead, the M bit should only be used in 442 a Neighbors2 message as described in Appendix B. The bit marked S 443 stands for SNMP capable. This bit is used by troubleshooting 444 applications and should only be tested in the Neighbors2 message. 446 The N bit (which stands for Netmask) is defined by this 447 specification. It is used to indicate the neighbor will accept 448 network masks appended to the Prune, Graft, and Graft Ack messages. 449 This bit only indicates that the neighbor understands the netmask. It 450 DOES NOT mean that Prune, Graft, and Graft Ack messages sent to this 451 neighbor must include a netmask. Refer to the sections on Prune, 452 Graft, and Graft Ack messages for more details. 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 A time of day clock provides a good source for a non-decreasing 32 483 bit integer. 485 3.2.3. Neighbor Addresses 487 As a DVMRP router sees Probe messages from its DVMRP neighbors, it 488 records the neighbor addresses on each interface and places them in 489 the Probe message sent on the particular interface. This allows the 490 neighbor router to know that its probes have been received by the 491 sending router. 493 In order to minimize one-way neighbor relationships, a router MUST 494 delay sending poison route reports in response to routes advertised 495 by a neighbor until the neighbor includes the routers address in its 496 probe messages. On point-to-point interfaces and tunnel pseudo- 497 interfaces, this means that no packets should be forwarded onto these 498 interfaces until two-way neighbor relationships have formed. 500 Implementations written before this specification will not wait 501 before sending reports nor will they ignore reports sent. Therefore, 502 reports from these implementations SHOULD be accepted whether or not 503 a probe with the routers address has been received. 505 3.2.4. Neighbor Time-Out 507 When a neighbor times out, the following steps should be taken: 509 1. All routes learned from this neighbor should be immediately placed 510 in hold-down. All downstream dependencies ON this neighbor should 511 be removed. 513 2. If this neighbor is considered to be the designated forwarder for 514 any of the routes it is advertising, a new designated forwarder 515 for each source network should be selected. 517 3. Any forwarding cache entries based on this upstream neighbor 518 should be flushed. 520 4. Any outstanding Grafts awaiting acknowledgments from this router 521 should be flushed. 523 5. All downstream dependencies received FROM this neighbor should be 524 removed. Forwarding cache entries should be checked to see if 525 this is the last downstream dependent neighbor on the interface. 526 If so, and this router isn't the designated forwarder (with local 527 group members present), the interface should be removed. If the 528 last downstream interface is removed, a prune should be sent 529 upstream. 531 3.2.5. Probe Packet Format 533 The Probe packet is variable in length depending on the number of 534 neighbor IP addresses included. The length of the IP packet can be 535 used to determine the number of neighbors in the Probe message. The 536 current Major Version is 3. 538 7 15 23 31 539 +---------+--------------+--------------------+ 540 | Type | Code | Checksum | 541 | (0x13) | (0x1) | | 542 +---------+--------------+----------+---------+ 543 | | | | | 544 |Reserved | Capabilities | Minor | Major | 545 +---------+--------------+----------+---------+ 546 | | 547 | Generation ID | 548 +---------------------------------------------+ 549 | | 550 | Neighbor IP Address 1 | 551 +---------------------------------------------+ 552 | | 553 | Neighbor IP Address 2 | 554 +---------------------------------------------+ 555 | | 556 | ... | 557 +---------------------------------------------+ 558 | | 559 | Neighbor IP Address N | 560 +---------------------------------------------+ 562 Figure 3 - DVMRP Probe Packet Format 564 Generation ID 565 This field contains a non-decreasing number used to detect a 566 change in neighbor state. 568 Neighbor IP Address N 569 This is a list of Neighbor IP addresses whom the sending router 570 has received Probe messages from. 572 3.2.6. IGMP Designated Querier Election 574 Since it is wasteful to have more than a single router sending IGMP 575 Host Membership Queries on a given physical network, a single router 576 on each physical network is elected as the Designated Querier. This 577 election was formerly a part of DVMRP. However, this is now 578 specified as a part of the IGMP version 2 protocol. See Appendix C 579 for details on backwards compatibility. 581 Even though only one router will act as the IGMP designated querier, 582 all DVMRP routers must use IGMP to learn local group memberships. 584 3.3. Building Forwarding Cache Entries 586 In order to create multicast delivery trees, DVMRP was designed to 587 keep separate forwarding cache entries for each (source network, 588 destination group) pair. Because the possible combinations of these 589 is quite large, forwarding cache entries are generated on demand as 590 data arrives at a multicast router. Since the IP forwarding decision 591 is made on a hop by hop basis (as with the unicast case), it is 592 imperative that each multicast router has a consistent view of the 593 reverse path back to the source network. 595 3.3.1. Designated Forwarder 597 Initially, a DVMRP router should assume it is the designated 598 forwarder for all source networks on all downstream interfaces. As it 599 receives route reports, it can determine if other routers on multi- 600 access networks have better routes back to a particular source 601 network. A route is considered better if the adjusted received metric 602 is less than the metric that it will advertise for the source network 603 on the received interface or if the metrics are the same but the IP 604 address of the neighbor is lower. 606 If this neighbor becomes unreachable or starts advertising a worse 607 metric, then the router should become the designated forwarder for 608 this source network again on the downstream interface until it hears 609 from a better candidate. 611 If the upstream RPF interface changes, then the router should become 612 the designated forwarder on the previous upstream interface (which is 613 now a potential downstream interface) until it hears from a better 614 candidate. 616 3.3.2. Determining the upstream interface 618 When a multicast packet arrives, a DVMRP router will use the DVMRP 619 routing table to determine which interface leads back to the source. 621 If the packet did not arrive on that interface, it MUST be discarded 622 without further processing. Each multicast forwarding entry should 623 cache the upstream interface for a particular source host or source 624 network after looking this up in the DVMRP routing table. 626 3.3.3. Determining the downstream interface list 628 The downstream interface list is built from the remaining list of 629 multicast capable interfaces. Any interfaces designated as leaf 630 networks that do not have members of the particular multicast group 631 are automatically removed from list of downstream interfaces. The 632 remaining interfaces will either have downstream DVMRP routers or 633 directly attached group members. If the router is not the designated 634 forwarder on interfaces with directly attached group members, these 635 interfaces are removed as well. This prevents duplicate packets from 636 arriving on multi-access networks. Finally, interfaces on which all 637 downstream dependent neighbors have sent prunes are removed as well 638 (if there are no group members). 640 3.4. Route Exchange 642 The routing information propagated by DVMRP is used for determining 643 the reverse path neighbor back to the source of the multicast 644 traffic. The interface used to reach this neighbor is called the 645 upstream interface. Tunnel pseudo-interfaces are considered to be 646 distinct from the physical interface on which the packet is actually 647 transmitted for the purpose of determining upstream and downstream 648 interfaces. 650 The routing information that is propagated by DVMRP contains a list 651 of source networks and an appropriate metric. The metric used is a 652 hop count which is incremented by the cost of the incoming interface 653 metric. Traditionally, physical interfaces use a metric of 1 while 654 the metric of a tunnel interface varies with the distance and 655 bandwidth in the path between the two tunnel endpoints. Users are 656 encouraged to configure tunnels with the same metric in each 657 direction to create symmetric routing and provide for easier problem 658 determination although the protocol does not strictly enforce this. 660 3.4.1. Source Network Aggregation 661 Implementations may wish to provide a mechanism to aggregate source 662 networks to reduce the size of the routing table. All implementations 663 should be able to accept reports for aggregated source networks in 664 accordance with Classless Inter-Domain Routing (CIDR) as described in 665 [Rekh93] and [Full93]. 667 There are two places where aggregation is particularly useful. 669 1. At organizational boundaries to limit the number of source 670 networks advertised out of the organization. 672 2. Within an organization to summarize non-local routing information 673 by using a default (0/0) route. 675 If an implementation wishes to support source aggregation, it MUST 676 transmit Prune and Graft messages according to the following rules: 678 A. If a Prune is received on a downstream interface for which the 679 source network advertised to that neighbor is an aggregate 680 generated by the receiving router, then the aggregating router 681 should pretend as though prunes were received for each 682 contributing routes of the aggregated route. If this is the last 683 downstream dependent neighbor, this may trigger a prune to be sent 684 upstream to the longest match contributing route of the aggregate 685 route determined by the source address in the received prune. 687 There may be active forwarding cache entries for other 688 contributing routes to the aggregate. Prunes should not be sent 689 upstream to the contributing routes that have no forwarding state. 690 The downstream interface on which the aggregated prune was 691 received should be removed from these forwarding cache entries. 692 This may trigger a prune being sent upstream for these 693 contributing routes. However, since these sources may no longer 694 be active, it might be preferable to wait until data arrives from 695 these other contributing sources before sending prunes to each 696 one. This reduces the control traffic and minimizes the number of 697 prunes sent to only active sources. 699 In order to be notified when data arrives, the forwarding cache 700 entries based on these contributing routes should be removed from 701 the forwarding path in order to trigger the on-demand route lookup 702 and prune response. 704 If data from another contributing route of the aggregated network 705 is received by the aggregating router at a later time, the 706 aggregating router should remember that a prune was received for 707 this contributing route by the downstream neighbor who previously 708 sent the aggregated prune. This may trigger sending a prune 709 upstream for the contributed route. 711 B. If a Graft is received on a downstream interface for which the 712 source network advertised to that neighbor is an aggregate 713 generated by the receiving router, then Graft messages MUST be 714 sent upstream (if necessary) for each route that contributed to 715 the aggregate that had been previously pruned. 717 3.4.2. Route Packing and Ordering 719 Since DVMRP Route Reports may need to refresh several thousand routes 720 each report interval, routers MUST attempt to spread the routes 721 reported across the whole route update interval. This reduces the 722 chance of synchronized route reports causing routers to become 723 overwhelmed for a few seconds each report interval. Since the route 724 report interval is 60 seconds, it is suggested that the total number 725 routes being updated be split across multiple Route Reports sent at 726 regular intervals. There was an earlier requirement that Route 727 Reports MUST contain source network/mask pairs sorted first by 728 increasing network mask and then by increasing source network. This 729 restriction has been lifted. Implementations conforming to this 730 specification MUST be able to receive Route Reports containing any 731 mixture of network masks and source networks. 733 In order to pack more source networks into a route report, source 734 networks are often represented by less than 4 octets. The number of 735 non-zero bytes in the mask value is used to determine the number of 736 octets used to represent each source network within that particular 737 mask value. For instance if the mask value of 255.255.0.0 is being 738 reported, the source networks would only contain 2 octets each. DVMRP 739 assumes that source networks will never be aggregated into networks 740 whose prefix length is less than 8. Therefore, it does not carry the 741 first octet of the mask in the Route Report since, given this 742 assumption, the first octet will always be 0xFF. This means that the 743 netmask value will always be represented in 3 octets. This method of 744 specifying source network masks is compatible with techniques 745 described in [Rekh93] and [Full93] to group traditional Class C 746 networks into super-nets and to allow different subnets of the same 747 Class A network to be discontinuous. It does not, however, allow 748 grouping class A networks into super-nets since the first octet of 749 the netmask is always assumed to be 255. 751 In this notation, the default route is represented as the least three 752 significant octets of the netmask [00 00 00], followed by one octet 753 for the network number [00]. This special case MUST be interpreted 754 as 0.0.0.0/0.0.0.0 and NOT 0.0.0.0/255.0.0.0. 756 3.4.3. Route Metrics 758 For each source network reported, a route metric is associated with 759 the route being reported. The metric is the sum of the interface 760 metrics between the router originating the report and the source 761 network. For the purposes of DVMRP, the Infinity metric is defined to 762 be 32. This limits the breadth across the whole DVMRP network and is 763 necessary to place an upper bound on the convergence time of the 764 protocol. 766 As seen in the packet format below, Route Reports do not contain a 767 count of the number of routes reported for each netmask. Instead, a 768 "Last" bit is defined as the high order bit of the octet following 769 the network address. This bit is set to signify when the last route 770 is being reported for a particular mask value. When the "Last" bit 771 is set and the end of the message has not been reached, the next 772 value will be a new netmask to be applied to the subsequent list of 773 routes. 775 3.4.4. Route Dependencies 777 In order for pruning to work correctly, each DVMRP router needs to 778 know which downstream routers depend on it for receiving datagrams 779 from particular source networks. Initially, when a new datagram 780 arrives from a particular source/group pair, it is broadcasted to all 781 downstream interfaces that have DVMRP neighbors who have indicated a 782 dependency on the receiving DVMRP router for that particular source. 783 A downstream interface can only be removed when the router has 784 received Prune messages from each of the dependent routers on that 785 interface. Each downstream router uses Poison Reverse to indicate 786 for which source networks it is dependent upon the upstream router. 787 The downstream router indicates this by echoing back the source 788 networks it expects to receive from the upstream router with infinity 789 added to the advertised metric. This means that the legal values for 790 the metric now become between 1 and (2 x Infinity - 1) or 1 and 63. 791 Values between 1 and 31 indicate reachable source networks. The value 792 Infinity (32) indicates the source network is not reachable. Values 793 between 33 and 63 indicate that the downstream router originating the 794 Report is depending upon the upstream router to provide multicast 795 datagrams from the corresponding source network. 797 3.4.5. Sending Route Reports 799 All of the active routes MUST be advertised over all interfaces with 800 neighbors present each Route Report Interval. In addition, flash 801 updates MAY be sent as needed but flash updates MUST NOT happen more 802 often than the Minimum Flash Update Interval (5 seconds). Flash 803 updates reduce the chances of routing loops and black holes occurring 804 when source networks become unreachable through a particular path. 805 Flash updates need only contain the source networks that have 806 changed. 808 When a router sees its own address in a neighbor probe packet for the 809 first time, it should send a unicast copy of its entire routing table 810 to the neighbor to reduce start-up time. 812 Reports should not be sent to a neighbor until a router has seen its 813 own address in the neighbors Probe router list. See Appendix C for 814 exceptions. 816 3.4.6. Receiving Route Reports 818 After receiving a route report, a check should be made to verify it 819 is from a known neighbor. Two-way neighbor relationships are 820 essential for proper DVMRP operation. Therefore, route reports from 821 unknown neighbors MUST be discarded. 823 In the following discussion, "Metric" refers to the metric of the 824 route as received in the route report. "Adjusted Metric" refers to 825 the metric of the route after the incoming interface metric has been 826 added. 828 If the metric received is less than infinity but the Adjusted Metric 829 is greater than or equal to infinity, the Adjusted Metric should be 830 set to infinity. 832 If the metric is greater than or equal to infinity, then no 833 adjustment of the metric should be made. 835 Each route in the report is then parsed and processed according to 836 the following rules: 838 A. If the route is new and the Adjusted Metric is less than infinity, 839 the route should be added. 841 If the new route overlaps an existing route for which prunes have 842 been received from downstream neighbors, the prune state of the 843 less specific route that falls within the range of the more 844 specific route should be deleted. 846 B. If the route already exists, several checks must be performed. 848 1. Received Metric < infinity 850 If the neighbor was considered a downstream dependent neighbor, 851 the dependency is canceled. Check to determine if removing this 852 neighbor triggers a Prune. 854 In the following cases, the designated forwarder on one of the 855 downstream interfaces should be updated: 857 - If the Metric received would cause the router to advertise a 858 better metric on a downstream interface than the existing 859 designated forwarder for the source network on that 860 interface (or advertised metric would be the same but the 861 router's IP address is lower than the existing designated 862 forwarder on that interface). Then the receiving router 863 becomes the new designated forwarder for that source network 864 on that interface. This may trigger a graft to be sent 865 upstream. 867 - If the metric being advertised by the current designated 868 forwarder is worse than the receiving routers metric that it 869 would advertise on the receiving interface (from learning 870 the same route from a neighbor on another interface) or the 871 metric is the same but the receiving router has a lower IP 872 address, then the receiving router becomes the new 873 designated forwarder on that interface. This may trigger a 874 graft to be sent upstream. 876 - If the metric received for the source network is better than 877 the metric of the existing designated forwarder, save the 878 new designated forwarder and the metric it is advertising. 879 It is necessary to maintain knowledge of the current 880 designated forwarder for each source network in case the 881 time-out value for this neighbor is reached. If the time-out 882 is reached, then the designated forwarder responsibility for 883 the source network should be assumed. 885 A route is considered better when either the received Metric is 886 lower than the existing metric or the received Metric is the 887 same but the advertising router's IP address is lower. 889 a. Adjusted Metric > existing metric 891 If the Adjusted Metric is greater than the existing metric, 892 then check to see if the same neighbor is reporting the 893 route. If so, update the route metric and schedule a flash 894 update containing the route. Otherwise, skip to the next 895 route in the report. 897 b. Adjusted Metric < existing metric 899 Update the metric for the route and if the neighbor 900 reporting the route is different, update the upstream 901 neighbor in the routing table. Schedule a flash update 902 containing the route to downstream neighbors and a flash 903 poison update containing the route should be sent upstream 904 indicating a change in downstream dependency (even if its on 905 the same upstream interface). 907 c. Adjusted metric = existing metric 909 If the neighbor reporting the route is the same as the 910 existing upstream neighbor, then simply refresh the route. 911 If the neighbor is the same and the route is in hold-down, 912 it is permissible to prematurely take the route out of hold- 913 down and begin advertising it with a non-infinity metric. 914 If the route is taken out of hold-down, a flash update 915 containing the route should be scheduled on all DVMRP 916 interfaces except the one over which it was received. 918 If the neighbor reporting the route has a lower IP address 919 than the existing upstream neighbor, then switch to this 920 neighbor as the best route. Schedule a flash update 921 containing the route to downstream neighbors and a flash 922 poison update containing the route should be sent upstream 923 indicating a change in downstream dependency (even if its on 924 the same upstream interface). 926 2. Received Metric = infinity 927 If the neighbor was considered to be the designated 928 forwarder, the receiving router should now become the 929 designated forwarder for the source network on this 930 interface. 932 a. Next hop = existing next hop 933 If the existing metric was less than infinity, the route is 934 now unreachable. Delete the route and schedule a flash 935 update containing the route to all interfaces for which you 936 are the designated forwarder or have downstream dependents. 938 b. Next hop != existing next hop 940 The route can be ignored since the existing next hop has a 941 metric better than or equal to this next hop. 943 If the neighbor was considered a downstream dependent 944 neighbor, this should be canceled. Check to determine if 945 removing this neighbor triggers a Prune. 947 3. infinity < Received Metric < 2 x infinity 949 The neighbor considers the receiving router to be upstream for 950 the route and is indicating it is dependent on the receiving 951 router. 953 If the neighbor was considered to be the designated forwarder, 954 the receiving router should now become the designated forwarder 955 for the source network on this interface. 957 a. Neighbor on downstream interface 959 If the sending neighbor is considered to be on a downstream 960 interface for that route then the neighbor is to be 961 registered as a downstream dependent router for that route. 963 If this is the first time the neighbor has indicated 964 downstream dependence for this source and one or more prunes 965 have been sent upstream containing this source network, then 966 Graft messages MUST be sent upstream in the direction of the 967 source network for each group with existing prune state. 969 b. Neighbor on upstream interface 971 If the receiving router thinks the neighbor is on the 972 upstream interface, then the route should be treated as if 973 an infinity metric was received (See Received Metric = 974 infinity). 976 4. 2 x infinity <= Received Metric 977 If the Received Metric is greater than or equal to 2 x 978 infinity, the Metric is illegal and the route should be 979 ignored. 981 3.4.7. Route Expiration 983 A route expires if it has not been refreshed within the Route 984 Expiration time. This should be set to 2 x Route Report Interval + 20 985 (or 140) seconds. Due to flash updates, routes will typically not 986 expire but instead be removed in response to receiving an infinity 987 metric for the route. However, since not all existing 988 implementations implement flash updates, route expiration is 989 necessary. 991 3.4.8. Route Hold-down 993 When a route is deleted (because it expires, the neighbor it was 994 learned from goes away, or an infinity metric is received for the 995 route) a router may be able to reach the source network described by 996 the route through an alternate gateway. However, in the presence of 997 complex topologies, often, the alternate gateway may only be echoing 998 back the same route learned via a different path. If this occurs, the 999 route will continue to be propagated long after it is no longer 1000 valid. 1002 In order to prevent this, it is common in distance vector protocols 1003 to continue to advertise a route that has been deleted with a metric 1004 of infinity for one or more report intervals. This is called Hold- 1005 down. A route MUST only be advertised with an infinity metric while 1006 it is in hold-down. The hold-down period is 2 Report Intervals. 1008 When a route goes into hold-down, all forwarding cache entries based 1009 on the route should be flushed. 1011 During the hold-down period, the route may be learned via a different 1012 gateway or the same gateway with a different metric. The router MAY 1013 use this new route for delivering to local group members. Also, 1014 installing a new route during the hold-down period allows the route 1015 to be advertised with a non-infinity metric more quickly once the 1016 hold-down period is over. 1018 In order to minimize outages caused by flapping routes, it is 1019 permissible to prematurely take a route out of hold-down ONLY if the 1020 route is re-learned from the SAME router with the SAME metric. 1022 Route hold-down is not effective if only some routers implement it. 1023 Therefore, it is now a REQUIRED part of the protocol. 1025 3.4.9. Graceful Shutdown 1027 During a graceful shutdown, an implementation MAY want to inform 1028 neighbor routers that it is terminating. Routes that have been 1029 advertised with a metric less than infinity should now be advertised 1030 with a metric equal to infinity. This will allow neighbor routers to 1031 switch more quickly to an alternate path for a source network if one 1032 exists. 1034 Routes that have been advertised with a metric between infinity and 2 1035 x infinity (indicating downstream neighbor dependence) should now be 1036 advertised with a metric equal to infinity (canceling the downstream 1037 dependence). 1039 3.4.10. Route Report Packet Format 1041 The format of a sample Route Report Packet is shown in Figure 4 1042 below. The packet shown is an example of how the source networks are 1043 packed into a Report. The number of octets in each Source Network 1044 will vary depending on the mask value. The values below are only an 1045 example for clarity and are not intended to represent the format of 1046 every Route Report. 1048 7 15 23 31 1049 +-----------+------------+-------------------------+ 1050 | Type | Code | Checksum | 1051 | (0x13) | (0x2) | | 1052 +-----------+------------+------------+------------+ 1053 | Reserved | Minor | Major | 1054 | | Version | Version | 1055 +-----------+------------+------------+------------+ 1056 | Mask1 | Mask1 | Mask1 | Src | 1057 | Octet2 | Octet3 | Octet4 | Net11 | 1058 +-----------+------------+------------+------------+ 1059 | SrcNet11(cont.)... | Metric11 | Src | 1060 | | | Net12 | 1061 +------------------------+------------+------------+ 1062 | SrcNet12(cont.)... | Metric12 | Mask2 | 1063 | | | Octet2 | 1064 +-----------+------------+------------+------------+ 1065 | Mask2 | Mask2 | SrcNet21 | 1066 | Octet3 | Octet4 | | 1067 +-----------+------------+------------+------------+ 1068 | SrcNet21(cont.)... | Metric21 | Mask3 | 1069 | | | Octet2 | 1070 +-----------+------------+------------+------------+ 1071 | Mask3 | Mask3 | ... | 1072 | Octet3 | Octet4 | | 1073 +-----------+------------+-------------------------+ 1075 Figure 4 - Example Route Report Packet Format 1077 3.5. Pruning 1079 DVMRP is described as a broadcast and prune multicast routing 1080 protocol since datagrams are initially sent out all dependent 1081 downstream interfaces forming a tree rooted at the source of the 1082 data. As the routers at the leafs of the tree begin to receive 1083 unwanted multicast traffic, they send prune messages upstream toward 1084 the source. This results in the multicast tree for a given source 1085 network and a given set of receivers. 1087 3.5.1. Leaf Networks 1089 Detection of leaf networks is very important to the pruning process. 1090 Routers at the end of a source specific multicast delivery tree must 1091 detect that there are no further downstream dependent routers. This 1092 detection mechanism is covered above in section 3.2 titled Probe 1093 Messages. If there are no group members present for a particular 1094 multicast datagram received, the leaf routers will start the pruning 1095 process by removing their downstream interfaces and sending a prune 1096 to the upstream router for that source. 1098 3.5.2. Source Networks 1100 By default, prunes are meant to be applied to a group and source 1101 network. However, it is possible to include a Netmask in the Prune 1102 message to alter this behavior. If no Netmask is included, a prune 1103 sent upstream triggered by traffic received from a particular source 1104 applies to all sources on that network. If a Netmask is included, it 1105 MUST first be validated. If the Netmask is a host mask, only that 1106 source address should be pruned. Otherwise, the Netmask MUST match 1107 the mask sent to the downstream router for that source. If it does 1108 not match the mask that the upstream router expected, the upstream 1109 router MUST ignore the prune and should log an error. When a 1110 aggregate source network is advertised downstream, the Netmask in the 1111 prune will match the mask of the aggregate route that was advertised. 1113 If the Prune message only contains the host address of the source 1114 (and not the corresponding Netmask), the source network can be 1115 determined easily by a best-match lookup using the routing table 1116 distributed as a part of DVMRP. 1118 3.5.3. Receiving a Prune 1120 When a prune is received, the following steps should be taken: 1122 1. If the neighbor is unknown, discard the received prune. 1124 2. Ensure the prune message contains at least the correct amount of 1125 data. 1127 3. Copy the source address, group address, and prune time-out value. 1128 If it is available in the packet, copy the Netmask value. 1129 Determine route to which prune applies. 1131 4. If there is no active source information for the (source network, 1132 group) pair, then ignore the prune. 1134 5. Verify that the prune was received from a dependent neighbor for 1135 the source network. If not, discard the prune. 1137 6. Determine if a prune is currently active from the same dependent 1138 neighbor for this (source network, group) pair. 1140 7. If so, reset the timer to the new time-out value. Otherwise, 1141 create state for the new prune and set a timer for the prune 1142 lifetime. 1144 8. Determine if all dependent downstream routers on the interface 1145 from which the prune was received have now sent prunes. 1147 9. If so, then determine if there are group members active on the 1148 interface. 1150 10. If no group members are found, then remove the interface from all 1151 forwarding cache entries instantiated using the route to which 1152 the prune applies. 1154 11. If all downstream interfaces have now been removed, send a prune 1155 to the upstream neighbor. 1157 3.5.4. Sending a Prune 1159 When sending a prune upstream, the following steps should be taken: 1161 1. Decide if upstream neighbor is capable of receiving prunes. 1163 2. If not, then proceed no further. 1165 3. Stop any pending Grafts awaiting acknowledgments. 1167 4. Determine the prune lifetime. This value should be the minimum of 1168 the default prune lifetime (randomized to prevent synchronization) 1169 and the remaining prune lifetimes of the downstream neighbors. 1171 5. Form and transmit the packet to the upstream neighbor for the 1172 source. 1174 3.5.5. Retransmitting a Prune 1176 By increasing the prune lifetime to ~2 hours, the effect of a lost 1177 prune message becomes more apparent. Therefore, an implementation 1178 SHOULD retransmit prunes messages using binary exponential back-off 1179 during the lifetime of the prune if traffic is still arriving on the 1180 upstream interface. 1182 One way to implement this would be to send a prune, install a 1183 negative cache entry for 3 seconds while waiting for the prune to 1184 take effect. Then remove the negative cache entry. If traffic 1185 continues to arrive, a new forwarding cache request will be 1186 generated. The prune can be resent with the remaining prune lifetime 1187 and a negative cache entry can be installed for 6 seconds. After 1188 this, the negative cache entry is removed. This procedure is repeated 1189 while each time doubling the length of time the negative cache entry 1190 is installed. 1192 In addition to using binary exponential back-off, the interval 1193 between subsequent retransmissions should also be randomized to 1194 prevent synchronization. 1196 On multi-access networks, even if a prune is received by the upstream 1197 router, data may still be received due to other receivers (i.e. group 1198 members or other downstream dependent routers) on the network. 1200 3.5.6. Prune Packet Format 1202 A Prune Packet contains three required fields: the source host IP 1203 address, the destination group IP address, and the Prune Lifetime in 1204 seconds. An optional source network mask may also be appended to the 1205 Prune message. This mask applied to the Source Host Address will 1206 indicate the route that the prune applies to. A Source Network Mask 1207 field should only be sent in a Prune message to a neighbor if that 1208 neighbor has advertised the ability to process it by setting the 1209 Netmask capabilities bit. The length of the Prune message will 1210 indicate if the Source Network Mask has been included or not. 1212 The Prune Lifetime is a derived value calculated as the minimum of 1213 the default prune lifetime (2 hours) and the remaining lifetimes of 1214 of any downstream prunes received for the same cache entry. A router 1215 with no downstream dependent neighbors would use the the default 1216 prune lifetime (randomized to prevent synchronization). 1218 7 15 23 31 1219 +-----------+------------+-------------------------+ 1220 | Type | Code | Checksum | 1221 | (0x13) | (0x7) | | 1222 +-----------+------------+------------+------------+ 1223 | Reserved | Minor | Major | 1224 +------------------------+------------+------------+ 1225 | Source Host Address | 1226 +--------------------------------------------------+ 1227 | Group Address | 1228 +--------------------------------------------------+ 1229 | Prune Lifetime | 1230 +--------------------------------------------------+ 1231 | Source Network Mask | 1232 +--------------------------------------------------+ 1234 Figure 5 - Prune Packet Format 1236 Source Host Address 1237 The source host IP address of the datagram that triggered the 1238 prune. 1240 Group Address 1241 The destination group IP address of the datagram that triggered 1242 the prune. 1244 Prune Lifetime 1245 The number of seconds for which the upstream neighbor should keep 1246 this prune active. 1248 Source Network Mask 1249 The (optional) netmask of the route this prune applies to. 1251 3.6. Grafting 1253 Once a multicast delivery tree has been pruned back, DVMRP Graft 1254 messages are necessary to join new receivers onto the multicast tree. 1255 Graft messages are sent upstream hop-by-hop from the new receiver's 1256 first-hop router until a point on the multicast tree is reached. 1257 Since there is no way to tell whether a graft message was lost or the 1258 source stopped sending, each Graft message is acknowledged hop by 1259 hop. This ensures that the Graft message is not lost somewhere along 1260 the path between the receiver's first-hop router and the closest 1261 point on the multicast delivery tree. 1263 One or more Graft messages should be sent under the following 1264 conditions: 1266 1. A new local member joins a group that has been pruned upstream. 1268 2. A new dependent downstream router appears on a pruned branch. 1270 3. A dependent downstream router on a pruned branch restarts (new 1271 Generation ID). 1273 4. A Graft Retransmission Timer expires before a Graft-Ack is 1274 received. 1276 3.6.1. Sending a Graft 1278 Recall that by default, Prunes are source network specific and are 1279 sent up different trees for each source network. Grafts are sent in 1280 response to various conditions which are not necessarily source 1281 specific. Therefore, it may be necessary to send separate Graft 1282 messages to the appropriate upstream routers to counteract each 1283 previous source network specific prune that was sent. 1285 As mentioned above, a Graft message sent to the upstream DVMRP router 1286 should be acknowledged hop by hop guaranteeing end-to-end delivery. 1287 In order to send a Graft message, the following steps should be 1288 taken: 1290 1. Verify a forwarding cache entry exists for the (source network, 1291 group) pair and that a prune exists for the cache entry. 1293 2. Verify that the upstream router is capable of receiving prunes 1294 (and therefore grafts). 1296 3. Add the graft to the retransmission timer list awaiting an 1297 acknowledgment. 1299 4. Formulate and transmit the Graft packet. 1301 If a Graft Acknowledgment is not received within the Graft 1302 Retransmission Time-out period, the Graft should be resent to the 1303 upstream router. The initial retransmission period is 5 seconds. A 1304 binary exponential back-off policy is used on subsequent 1305 retransmissions. 1307 3.6.2. Receiving a Graft 1309 1. If the neighbor is unknown, discard the received graft. 1311 2. Ensure the graft message contains at least the correct amount of 1312 data. 1314 3. Send back a Graft Ack to the sender. 1316 4. If the sender was a downstream dependent neighbor from which a 1317 prune had previously been received, then remove the prune state 1318 for this neighbor. If necessary, any forwarding cache entries 1319 based on this (source, group) pair should be updated to include 1320 this downstream interface. 1322 5. If a prune had been sent upstream, this may trigger a graft to 1323 now be sent to the upstream router. 1325 3.6.3. Graft Packet Format 1327 The format of a Graft packet is show below: 1329 7 15 23 31 1330 +-----------+------------+-------------------------+ 1331 | Type | Code | Checksum | 1332 | (0x13) | (0x8) | | 1333 +-----------+------------+------------+------------+ 1334 | Reserved | Minor | Major | 1335 +------------------------+------------+------------+ 1336 | Source Host Address | 1337 +--------------------------------------------------+ 1338 | Group Address | 1339 +--------------------------------------------------+ 1340 | Source Network Mask | 1341 +--------------------------------------------------+ 1343 Figure 6 - Graft Packet Format 1345 Source Host Address 1346 The source host IP address indicating which source host or source 1347 network to Graft. 1349 Group Address 1350 The destination group IP address to be grafted. 1352 Source Network Mask 1353 The (optional) netmask of the route this graft applies to. 1355 3.6.4. Sending a Graft Acknowledgment 1357 A Graft Acknowledgment packet is sent to a downstream neighbor in 1358 response to receiving a Graft message. All Graft messages MUST be 1359 acknowledged. This is true even if no other action is taken in 1360 response to receiving the Graft to prevent the source from 1361 continually re-transmitting the Graft message. The Graft 1362 Acknowledgment packet is identical to the Graft packet except that 1363 the DVMRP code in the common header is set to Graft Ack. This allows 1364 the receiver of the Graft Ack message to correctly identify which 1365 Graft was acknowledged and stop the appropriate retransmission timer. 1367 3.6.5. Receiving a Graft Acknowledgment 1369 When a Graft Acknowledgment is received, ensure the message contains 1370 at least the correct amount of data. The (source address, group) 1371 pair in the packet can be used to determine if a Graft was sent to 1372 this particular upstream router. If no Graft was sent, the Graft Ack 1373 can simply be ignored. If a Graft was sent, and the acknowledgment 1374 has come from the correct upstream router, then it has been 1375 successfully received and the retransmission timer for the Graft can 1376 be stopped. 1378 3.6.6. Graft Acknowledgment Packet Format 1380 The format of a Graft Ack packet (which is identical to that of a 1381 Graft packet) is show below: 1383 7 15 23 31 1384 +-----------+------------+-------------------------+ 1385 | Type | Code | Checksum | 1386 | (0x13) | (0x9) | | 1387 +-----------+------------+------------+------------+ 1388 | Reserved | Minor | Major | 1389 +------------------------+------------+------------+ 1390 | Source Host Address | 1391 +--------------------------------------------------+ 1392 | Group Address | 1393 +--------------------------------------------------+ 1394 | Source Network Mask | 1395 +--------------------------------------------------+ 1397 Figure 7 - Graft Ack Packet Format 1399 Source Host Address 1400 The source host IP address that was received in the Graft message. 1402 Group Address 1403 The destination group IP address that was received in the Graft 1404 message. 1406 Source Network Mask 1407 The (optional) netmask of the route this Graft Ack applies to. 1409 3.7. Interfaces 1411 Interfaces running DVMRP will either be multicast capable physical 1412 interfaces or encapsulated tunnel pseudo-interfaces. Physical 1413 interfaces may either be multi-access networks or point-to-point 1414 networks. Tunnel interfaces are used when there are non-multicast 1415 capable routers between DVMRP neighbors. Protocol messages and 1416 multicast data traffic are sent between tunnel endpoints using a 1417 standard encapsulation method [Perk96,Han94a,Han94b]. The unicast IP 1418 addresses of the tunnel endpoints are used as the source and 1419 destination IP addresses in the outer IP header. The inner IP header 1420 remains unchanged from the original packet. 1422 Protocol messages on point-to-point links should always use a 1423 destination IP address of All-DVMRP-Routers for ALL message types. 1424 While Prune, Graft, and Graft-Ack messages are only intended for a 1425 single recipient, the use of a multicast destination address is 1426 necessary for un-numbered links and encapsulated interfaces. 1428 When multiple addresses are configured on a single interface, it is 1429 necessary that all routers on the interface know about the same set 1430 of network addresses. In this way, each router will make the same 1431 choice for the designated forwarder for each source. In addition, a 1432 router configured with multiple addresses on an interface should 1433 consistently use the same address when sending DVMRP control 1434 messages. 1436 The maximum packet length of any DVMRP message should be the maximum 1437 packet size required to be forwarded without fragmenting. The use of 1438 Path MTU Discovery [Mogu90] is encouraged to determine this size. In 1439 the absence of Path MTU, the Requirements for Internet Hosts [Brad89] 1440 specifies this number as 576 octets. Be sure to consider the size of 1441 the encapsulated IP header as well when calculating the maximum size 1442 of a DVMRP protocol message. 1444 4. IANA Considerations 1446 The Internet Assigned Numbers Authority (IANA) is the central 1447 coordinator for the assignment of unique parameter values for 1448 Internet protocols. DVMRP uses IGMP [Fen97a] IP protocol messages to 1449 communicate between routers. The IGMP Type field is hexadecimal 0x13. 1451 On IP multicast capable networks, DVMRP uses the All-DVMRP-Routers 1452 local multicast group. This group address is 224.0.0.4. 1454 5. Network Management Considerations 1456 DVMRP provides several methods for network management monitoring and 1457 troubleshooting. Appendix B describes a request/response mechanism to 1458 directly query DVMRP neighbor information. In addition, a Management 1459 Information Base for DVMRP is defined in [Thal97]. 1461 A Management Information Base for the multicast forwarding cache is 1462 defined in [McCl98]. 1464 Also, a protocol independent multicast trace-route facility is 1465 defined in [Fen97b]. 1467 6. Security Considerations 1469 Security for DVMRP follows the general security architecture provided 1470 for the Internet Protocol [Ken98a]. This framework provides for both 1471 privacy and authentication. It recommends the use of the IP 1472 Authentication Header [Ken98b] to provide trusted neighbor 1473 relationships. Confidentiality is provided by the addition of the IP 1474 Encapsulating Security Payload [Ken98c]. 1476 7. References 1478 [Brad88] Braden, R., Borman, D., Partridge, C., "Computing the 1479 Internet Checksum", RFC 1071, September 1988. 1481 [Brad89] Braden, R., "Requirements for Internet Hosts -- 1482 Communication Layers", RFC 1122, October 1989. 1484 [Deer89] Deering, S., "Host Extensions for IP Multicasting", RFC 1485 1112, August 1989. 1487 [Deer90] Deering, S., Cheriton, D., "Multicast Routing in Datagram 1488 Internetworks and Extended LANs", ACM Transactions on 1489 Computer Systems, Vol. 8, No. 2, May 1990, pp. 85-110. 1491 [Deer91] Deering, S., "Multicast Routing in a Datagram 1492 Internetwork", PhD thesis, Electric Engineering Dept., 1493 Stanford University, December 1991. 1495 [Fen97a] Fenner, W., "Internet Group Management Protocol, Version 1496 2", RFC 2236, November 1997. 1498 [Fen97b] Fenner, W., Casner, S., "A "traceroute" facility for IP 1499 Multicast", Work In Progress, November 1997. 1501 [Full93] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 1502 Inter-Domain Routing (CIDR): an Address Assignment and 1503 Aggregation Strategy", RFC 1519, September 1993. 1505 [Han94a] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic 1506 Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and 1507 cisco Systems, October 1994. 1509 [Han94b] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1510 Routing Encapsulation over IPv4 networks", RFC 1702, 1511 NetSmiths, Ltd., cisco Systems, October 1994. 1513 [Ken98a] Kent, S., Atkinson, R. "Security Architecture for the 1514 Internet Protocol", Work in Progress, February 1998. 1516 [Ken98b] Kent, S., Atkinson, R., "IP Authentication Header", Work in 1517 Progress, February 1998. 1519 [Ken98c] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 1520 (ESP)", Work in Progress, February 1998. 1522 [McCl98] McCloghrie, K., Farinacci, D., Thaler, D., "IP Multicast 1523 Routing MIB", Work In Progress, July 1998. 1525 [Mogu90] Mogul, J., Deering, S., "Path MTU Discovery", RFC 1191, 1526 November 1990. 1528 [Perk96] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1529 October 1996. 1531 [Perl92] Perlman, R., "Interconnections: Bridges and Routers", 1532 Addison-Wesley, May 1992, pp. 205-211. 1534 [Post81] Postel, J., "Internet Protocol", RFC 791, September, 1981. 1536 [Rekh93] Rekhter, Y., and T. Li, "An Architecture for IP Address 1537 Allocation with CIDR", RFC 1518, September 1993. 1539 [Reyn94] Reynolds, J., Postel, J., "Assigned Numbers", STD 0002, 1540 October 1994. 1542 [Thal97] Thaler, D., "Distance-Vector Multicast Routing Protocol 1543 MIB", Work In Progress, April 1997. 1545 [Wait88] Waitzman, D., Partridge, C., Deering, S., "Distance Vector 1546 Multicast Routing Protocol", RFC 1075, November 1988. 1548 8. Author's Address 1550 Thomas Pusateri 1551 Juniper Networks, Inc. 1552 385 Ravendale Dr. 1553 Mountain View, CA 94043 1554 Phone: (919) 558-0700 1555 EMail: pusateri@juniper.net 1557 9. Acknowledgments 1559 The author would like to acknowledge the original designers of the 1560 protocol, Steve Deering, Craig Partridge, and David Waitzman. 1561 Version 3 of the protocol would not have been possible without the 1562 original work of Ajit Thyagarajan and the ongoing (and seemingly 1563 endless) work of Bill Fenner. Credit also goes to Danny Mitzel and 1564 Dave Thaler for the careful review of this document and Nitin Jain, 1565 Dave LeRoy, Charles Mumford, Ravi Shekhar, and Shuching Shieh for 1566 their helpful comments. 1568 10. Appendix A - Constants & Configurable Parameters 1570 The following table provides a summary of the DVMRP timing 1571 parameters: 1573 Parameter Value (seconds) 1574 ---------------------------------------------------------- 1575 Probe Interval 10 1576 Neighbor Time-out Interval 35 1577 Minimum Flash Update Interval 5 1578 Route Report Interval 60 1579 Route Expiration Time 140 1580 Route Hold-down 2 x Route Report Interval 1581 Prune Lifetime variable (< 2 hours) 1582 Prune Retransmission Time 3 with exp. back-off 1583 Graft Retransmission Time 5 with exp. back-off 1584 ---------------------------------------------------------- 1586 Table 2 - Parameter Summary 1588 11. Appendix B - Tracing and Troubleshooting support 1590 There are several packet types used to gather DVMRP specific 1591 information. They are generally used for diagnosing problems or 1592 gathering topology information. The first two messages are now 1593 obsoleted and should not be used. The remaining two messages provide 1594 a request/response mechanism to determine the versions and 1595 capabilities of a particular DVMRP router. 1597 Code Packet Type Description 1598 ----------------------------------------------------------- 1599 3 DVMRP Ask Neighbors Obsolete 1600 4 DVMRP Neighbors Obsolete 1601 5 DVMRP Ask Neighbors 2 Request Neighbor List 1602 6 DVMRP Neighbors 2 Respond with Neighbor List 1603 ----------------------------------------------------------- 1605 Table 3 - Debugging Packet Types 1607 11.1. DVMRP Ask Neighbors2 1609 The Ask Neighbors2 packet is a unicast request packet directed at a 1610 DVMRP router. The destination should respond with a unicast 1611 Neighbors2 message back to the sender of the Ask Neighbors2 message. 1613 0 8 16 31 1614 +---------+---------+--------------------+ 1615 | Type | Code | Checksum | 1616 |(0x13) | (0x5) | | 1617 +---------+---------+----------+---------+ 1618 | Reserved | Minor | Major | 1619 | | Version |Version | 1620 +-------------------+----------+---------+ 1622 Figure 8 - Ask Neighbors 2 Packet Format 1624 11.2. DVMRP Neighbors2 1626 The format of a Neighbors2 response packet is shown below. This is 1627 sent as a unicast message back to the sender of an Ask Neighbors2 1628 message. There is a common header at the top followed by the routers 1629 capabilities. One or more sections follow that contain an entry for 1630 each logical interface. The interface parameters are listed along 1631 with a variable list of neighbors learned on each interface. 1633 If the interface is down or disabled, list a single neighbor with an 1634 address of 0.0.0.0 for physical interfaces or the remote tunnel 1635 endpoint address for tunnel pseudo-interfaces. 1637 0 8 16 31 1638 +-----------+--------------+--------------------------+ 1639 | Type | Code | Checksum | 1640 | (0x13) | (0x6) | | 1641 +-----------+--------------+------------+-------------+ 1642 | Reserved | Capabilities | Minor | Major | 1643 | | | Version | Version | 1644 +-----------+--------------+------------+-------------+ 1645 | | 1646 | Local Addr 1 | 1647 +-----------+--------------+------------+-------------+ 1648 | | | | | 1649 | Metric 1 | Threshold 1 | Flags 1 | Nbr Count 1 | 1650 +-----------+--------------+------------+-------------+ 1651 | | 1652 | Nbr 1 | 1653 +-----------------------------------------------------+ 1654 | | 1655 | ... | 1656 +-----------------------------------------------------+ 1657 | | 1658 | Nbr m | 1659 +-----------------------------------------------------+ 1660 | | 1661 | Local Addr N | 1662 +-----------+--------------+------------+-------------+ 1663 | | | | | 1664 | Metric N | Threshold N | Flags N | Nbr Count N | 1665 +-----------+--------------+------------+-------------+ 1666 | | 1667 | Nbr 1 | 1668 +-----------------------------------------------------+ 1669 | | 1670 | ... | 1671 +-----------------------------------------------------+ 1672 | | 1673 | Nbr k | 1674 +-----------------------------------------------------+ 1676 Figure 9 - Neighbors 2 Packet Format 1678 The capabilities of the local router are defined as follows: 1680 Bit Flag Description 1681 --------------------------------------------------- 1683 0 Leaf This is a leaf router 1685 1 Prune This router understands pruning 1687 2 GenID This router sends Generation Id's 1689 3 Mtrace This router handles Mtrace requests 1691 4 Snmp This router supports the DVMRP MIB 1692 --------------------------------------------------- 1694 Table 4 - DVMRP Router Capabilities 1696 The flags associated with a particular interface are: 1698 Bit Flag Description 1699 ---------------------------------------------------------- 1701 0 Tunnel Neighbor reached via tunnel 1703 1 Source Route Tunnel uses IP source routing 1705 2 Reserved No longer used 1707 3 Reserved No longer used 1709 4 Down Operational status down 1711 5 Disabled Administrative status down 1713 6 Querier Querier for interface 1715 7 Leaf No downstream neighbors on interface 1716 ---------------------------------------------------------- 1718 Table 5 - DVMRP Interface flags 1720 12. Appendix C - Version Compatibility 1722 There have been two previous major versions of DVMRP with 1723 implementations still in circulation. If the receipt of a Probe 1724 message reveals a major version of 1 or 2, then it can be assumed 1725 that this neighbor does not support pruning or the use of the 1726 Generation ID in the Probe message. However, since these older 1727 implementations are known to safely ignore the Generation ID and 1728 neighbor information in the Probe packet, it is not necessary to send 1729 specially formatted Probe packets to these neighbors. 1731 There were three minor versions (0, 1, and 2) of major version 3 that 1732 did support pruning but did not support the Generation ID or 1733 capability flags. These special cases will have to be accounted for. 1735 Any other minor versions of major version 3 closely compare to this 1736 specification. 1738 In addition, cisco Systems is known to use their software major and 1739 minor release number as the DVMRP major and minor version number. 1740 These will typically be 10 or 11 for the major version number. 1741 Pruning was introduced in Version 11. 1743 Implementations prior to this specification may not wait to send 1744 route reports until probe messages have been received with the 1745 routers address listed. Reports SHOULD be sent to these neighbors 1746 without first requiring a received probe with the routers address in 1747 it as well as reports from these neighbors SHOULD be accepted. 1748 Although, this allows one-way neighbor relationships to occur, it 1749 does maintain backward compatibility. 1751 It may be necessary to form neighbor relationships based solely on 1752 Route Report messages. Neighbor timeout values may need to be 1753 configured to a value greater than the Route Report Interval for 1754 these neighbors. 1756 Implementations that do not monitor Generation ID changes can create 1757 more noticeable black holes when using long prune lifetimes such as 1758 ~2 hours. This happens when a long prune is sent upstream and then 1759 the router that sent the long prune restarts. If the upstream router 1760 ignores the new Generation ID, the prune received by the upstream 1761 router will not be flushed and the downstream router will have no 1762 knowledge of the upstream prune. For this reason, prunes sent 1763 upstream to routers that are known to ignore Generation ID changes 1764 should have short lifetimes. 1766 If the router must run IGMP version 1 on an interface for backwards 1767 compatibility, DVMRP must elect the DVMRP router with the highest IP 1768 address as the IGMP querier. 1770 Some implementations of tools that send DVMRP Ask Neighbors2 requests 1771 and receive Neighbors2 response messages require a neighbor address 1772 of 0.0.0.0 when no neighbors are listed in the response packet. 1773 (Mrinfo) 1775 When DVMRP protocol packets are sent to tunnel endpoints, some 1776 implementations do not accept packets addressed to the All-DVMRP- 1777 Routers address and then encapsulated with the tunnel endpoint 1778 address. Mrouted versions 3.9beta2 and earlier are known to have 1779 this problem. 1781 Table of Contents 1783 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1784 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . . 2 1785 1.2. Reverse Path Multicasting . . . . . . . . . . . . . . . . . 2 1786 1.3. Tunnel Encapsulation . . . . . . . . . . . . . . . . . . . . 2 1787 1.4. Document Overview . . . . . . . . . . . . . . . . . . . . . 3 1788 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 1789 2.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . 4 1790 2.2. Source Location . . . . . . . . . . . . . . . . . . . . . . 4 1791 2.3. Dependent Downstream Routers . . . . . . . . . . . . . . . . 5 1792 2.4. Designated Forwarder . . . . . . . . . . . . . . . . . . . . 6 1793 2.5. Building Multicast Trees . . . . . . . . . . . . . . . . . . 6 1794 2.6. Pruning Multicast Trees . . . . . . . . . . . . . . . . . . 7 1795 2.7. Grafting Multicast Trees . . . . . . . . . . . . . . . . . . 8 1796 3. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 8 1797 3.1. Protocol Header . . . . . . . . . . . . . . . . . . . . . . 8 1798 3.2. Probe Messages . . . . . . . . . . . . . . . . . . . . . . . 10 1799 3.3. Building Forwarding Cache Entries . . . . . . . . . . . . . 15 1800 3.4. Route Exchange . . . . . . . . . . . . . . . . . . . . . . . 16 1801 3.5. Pruning . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1802 3.6. Grafting . . . . . . . . . . . . . . . . . . . . . . . . . . 31 1803 3.7. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 35 1804 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 1805 5. Network Management Considerations . . . . . . . . . . . . . . 36 1806 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 1807 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 1808 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 38 1809 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 1810 10. Appendix A - Constants & Configurable Parameters . . . . . . 39 1811 11. Appendix B - Tracing and Troubleshooting support . . . . . . 40 1812 11.1. DVMRP Ask Neighbors2 . . . . . . . . . . . . . . . . . . . 40 1813 11.2. DVMRP Neighbors2 . . . . . . . . . . . . . . . . . . . . . 41 1814 12. Appendix C - Version Compatibility . . . . . . . . . . . . . 45