idnits 2.17.1 draft-ietf-idmr-dvmrp-v3-01.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-24) 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [Deer90]), 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. ** 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 356: '...igured for DVMRP SHOULD have an interv...' RFC 2119 keyword, line 357: '...time-out interval SHOULD be set at 140...' RFC 2119 keyword, line 359: '...y multicast routers. These values MUST...' RFC 2119 keyword, line 382: '...n the future and MUST be set to 0. Bit...' RFC 2119 keyword, line 383: '...ositions 1 and 2 MUST be set to 1 for ...' (5 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 295 has weird spacing: '...ets are encap...' == Line 320 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 (June 1996) is 10175 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) -- Looks like a reference, but probably isn't: '2' on line 34 == Unused Reference: 'Wait88' is defined on line 891, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Deer90' ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. 'Wait88') -- Possible downref: Non-RFC (?) normative reference: ref. 'Perk96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Fenn96' ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. 'Rekh93') ** Obsolete normative reference: RFC 1519 (ref. 'Full93') (Obsoleted by RFC 4632) Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 7 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 June 1996 5 draft-ietf-idmr-dvmrp-v3-01 Expires: December 1996 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), ds.internic.net (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 connectionless 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 [2]. 36 1. Introduction 38 1.1. Reverse Path Multicasting 40 Datagrams follow multicast delivery trees from a source to all 41 members of a multicast group [Deer89], replicating the packet only at 42 necessary branches in the delivery tree. The trees are calculated and 43 updated dynamically to track the membership of individual groups. 44 When a datagram arrives on an interface, the reverse path to the 45 source of the datagram is determined by examining a unicast routing 46 table of known source networks. If the datagram arrives on an 47 interface that would be used to transmit unicast datagrams back to 48 the source, then it is forwarded to the appropriate list of 49 downstream interfaces. Otherwise, it is not on the optimal delivery 50 tree and should be discarded. In this way duplicate packets can be 51 filtered when loops exist in the network topology. The source 52 specific delivery trees are automatically pruned back as group 53 membership changes or leaf routers determine that no group members 54 are present. This keeps the delivery trees to the minimum branches 55 necessary to reach all of the group members. New sections of the tree 56 can also be added dynamically as new members join the multicast group 57 by grafting the new sections onto the delivery trees. 59 1.2. IP-IP Tunnels 61 Because not all IP routers support native multicast routing, DVMRP 62 includes direct support for tunneling IP Multicast datagrams through 63 routers. The IP Multicast datagrams are encapsulated in unicast IP 64 packets and addressed to the routers that do support native multicast 65 routing. DVMRP treats tunnel interfaces in an identical manner to 66 physical network interfaces. More information on encapsulated tunnels 67 can be found in [Perk96]. 69 1.3. Document Overview 71 Section 2 provides an overview of the protocol and the different 72 message types exchanged by DVMRP routers. Those who wish to gain a 73 general understanding of the protocol but are not interested in the 74 more precise details may wish to only read this section. Section 3 75 explains the detailed operation of the protocol to accommodate 76 developers needing to provide interoperable implementations. 77 Included in Appendix A, is a summary of the DVMRP parameters. A 78 section on DVMRP support for tracing and troubleshooting is the topic 79 of Appendix B. Finally, a short DVMRP version compatibility section 80 is provided in Appendix C to assist with backward compatibility 81 issues. 83 2. Protocol Overview 85 DVMRP can be summarized as a "broadcast & prune" multicast routing 86 protocol. It performs Reverse Path Forwarding checks to determine 87 when multicast traffic should be forwarded to downstream interfaces. 88 In this way, minimum spanning trees can be formed to reach all group 89 members from each source network of multicast traffic. 91 2.1. Neighbor Discovery 93 Neighbor DVMRP routers can be discovered dynamically by sending 94 Neighbor Probe Messages on all of the local multicast capable network 95 interfaces. These messages are sent periodically to the All-DVMRP- 96 Routers IP Multicast group address. This address falls into the range 97 of IP Multicast addresses that are to remain on the locally attached 98 IP network and therefore are not forwarded by multicast routers. 99 Beginning with Version 3 of DVMRP outlined in this document, each 100 Neighbor Probe message should contain the list of Neighbor DVMRP 101 routers for which Neighbor Probe messages have been received. In this 102 way, Neighbor DVMRP routers can ensure that they are seen by each 103 other. Care must be taken to interoperate with older implementations 104 of DVMRP that do not include this list of neighbors. It can be 105 assumed that older implementations of DVMRP will safely ignore this 106 list of neighbors in the Probe message. Therefore, it is not 107 necessary to send both old and new types of Neighbor Probes. 109 2.2. Source Location 111 When an IP Multicast datagram is received by a router running DVMRP, 112 it first looks up the interface of the unicast route back to the 113 source of the datagram. This interface is called the upstream 114 interface. If the datagram arrived on the correct upstream interface, 115 then it is a candidate for forwarding to one or more downstream 116 interfaces. If the datagram did not arrive on the anticipated 117 upstream interface, it is discarded. This check is known as a reverse 118 path forwarding check and must be performed by all DVMRP routers. 120 In order to ensure that all DVMRP routers have a consistent view of 121 the unicast path back to a source, a unicast routing table is 122 propagated to all DVMRP routers as an integral part of the protocol. 123 Each router advertises the network number and mask of the interfaces 124 it is directly connected to as well as relaying the routes received 125 from neighbor routers. DVMRP allows for an interface metric to be 126 configured on all physical and tunnel interfaces. When a route is 127 received, the metric of the upstream interface over which the 128 datagram was received must be added to the metric of the route being 129 propagated. This adjusted metric should be computed before the route 130 is compared to the metric of the current next hop gateway. As is 131 customary with distance vector routing protocols, split horizon 132 should be applied to the route propagation policy in order to prevent 133 advertising a route to a destination over the interface from which it 134 was received. 136 Although there is certainly additional overhead associated with 137 propagating a separate unicast routing table, it does provide two 138 nice features. First, since all DVMRP routers are using the same 139 unicast routing protocol, there are no inconsistencies between 140 routers when determining the upstream interface (aside from normal 141 convergence issues related to distance vector routing protocols). By 142 placing the burden of synchronization on the protocol as opposed to 143 the network manager, DVMRP reduces the risk of creating routing loops 144 or blackholes due to disagreement between neighbor routers on the 145 upstream interface. 147 Second, by propagating its own unicast routing table, DVMRP makes it 148 convenient to have separate paths for unicast vs. multicast 149 datagrams. Although, ideally, many network managers would prefer to 150 keep their unicast and multicast traffic aligned, tunneled multicast 151 topologies may prevent this causing the unicast and multicast paths 152 to diverge. Additionally, service providers may prefer to keep the 153 unicast and multicast traffic separate for routing policy reasons as 154 they experiment with IP multicast routing and begin to offer it as a 155 service. For these benefits, DVMRP has chosen to accept the 156 additional overhead of propagating unicast routes. 158 2.3. Dependent Downstream Routers 160 In addition to providing a consistent view of source networks, the 161 exchange of unicast routes in DVMRP provides one other important 162 feature. DVMRP uses the unicast route exchange as a mechanism for 163 upstream routers to determine if any downstream routers depend on 164 them for forwarding from particular source networks. DVMRP 165 accomplishes this by using a well known technique called "Poison 166 Reverse". If a downstream router selects an upstream router as the 167 best next hop to a particular source network, this is indicated by 168 echoing back the route to the upstream router with a metric equal to 169 the original metric plus infinity. When the upstream router receives 170 the report and sees a metric that lies between infinity and twice 171 infinity, it can then add the downstream router from which it 172 received the report to a list of dependent routers for this source. 174 This list of dependent routers per source network built by the 175 "Poison Reverse" technique will provide the foundation necessary to 176 determine when it is appropriate to prune back the IP source specific 177 multicast trees. 179 2.4. Building Multicast Trees 181 As previously mentioned, when an IP multicast datagram arrives, the 182 upstream interface is determined by looking up the interface that 183 would be used if a datagram was being sent back to the source of the 184 datagram. If the upstream interface is correct, then a DVMRP router 185 will forward the datagram to a list of downstream interfaces. 187 2.4.1. Adding Leaf Networks 189 Initially, the DVMRP router must consider all of the remaining IP 190 multicast capable interfaces (including tunnels) on the router. If 191 the downstream interface under consideration is a leaf network (has 192 no other IP multicast routers on it), then the IGMP local group 193 database must be consulted. DVMRP routers can easily determine if a 194 directly attached network is a leaf network by keeping a list of all 195 routers from which DVMRP Router Probe messages have been received on 196 the interface. Obviously, it is necessary to refresh this list and 197 age out entries received from routers that are no longer being 198 refreshed. The IGMP local group database is maintained by an elected 199 IP multicast router on each physical, multicast capable network. The 200 details of the election procedure are discussed in section 3. If the 201 destination group address is listed in the local group database, then 202 the interface should be included in the list of downstream 203 interfaces. If there are no group members on the interface, then the 204 interface can be pruned from the candidate list. 206 2.4.2. Adding Non-Leaf Networks 208 Initially, all non-leaf networks should be included in the downstream 209 interface list when a forwarding cache entry is first being created. 210 This allows all downstream routers to be aware of traffic destined 211 for a particular (source, group) pair. The downstream routers will 212 then have the option to prune and graft this (source, group) pair to 213 and from the multicast delivery tree as requirements change from 214 their downstream routers and local group members. 216 2.5. Pruning Multicast Trees 218 As mentioned above, routers at the edges with leaf networks will 219 prune their leaf interfaces that have no group members associated 220 with an IP multicast datagram. If a router prunes all of its 221 downstream interfaces, it can notify the upstream router that it no 222 longer wants traffic destined for a particular (source, group) pair. 223 This is accomplished by sending a DVMRP Prune message upstream to the 224 router it expects to forward datagrams from a particular source. 225 Recall that a downstream router will inform an upstream router that 226 it depends on the upstream router to receive datagrams from 227 particular source networks by using the "Poison Reverse" technique 228 during the exchange of unicast routes. This method allows the 229 upstream router to build a list of downstream routers on each 230 interface that are dependent upon it for datagrams from a particular 231 source network. If the upstream router receives prune messages from 232 each one of the dependent downstream routers on an interface, then 233 the upstream router can in turn prune this interface from its 234 downstream interface list. If the upstream router is able to prune 235 all of its downstream interfaces in this way, it can then send a 236 DVMRP Prune message to its upstream router. This continues until the 237 minimum tree necessary to reach all of the receivers remains. Since 238 IP multicast routers may be restarted at any time and lose state 239 information about existing prunes, it is necessary to limit the life 240 of a prune and periodically resume the flooding procedure. This will 241 reinitiate the prune mechanism and the cycle will continue. When a 242 router decides to prune one of its downstream interfaces, it will set 243 a timer to indicate the lifetime of the prune. If all of its 244 downstream interfaces become pruned off the multicast delivery tree 245 and a DVMRP Prune message is sent upstream, the lifetime of the prune 246 will be equal to the minimum of the remaining lifetimes of the pruned 247 interfaces. 249 Pruning downstream interfaces is also necessary to prevent duplicate 250 packets from arriving on a multi-access network when there are 251 parallel paths back to a source. Since the routers use the "Poison 252 Reverse" technique during unicast route exchange, they will establish 253 which router will forward multicast traffic to the shared network and 254 prune the appropriate downstream interfaces based on the metrics of 255 the unicast routes exchanged. 257 2.6. Grafting Multicast Trees 259 Once a tree branch has been pruned from a multicast delivery tree, 260 packets from the pruned (source, group) pair will no longer be 261 forwarded. There are two different ways for packets from the 262 (source, group) pair to be forwarded again. First, since IP multicast 263 supports dynamic group membership, new hosts may join the multicast 264 group. In this case, DVMRP routers will need a mechanism to undo the 265 prunes that are in place from the host back to the first branch that 266 was pruned from the multicast tree. This is accomplished with a 267 DVMRP Graft message. A router will send a Graft message to its 268 upstream neighbor if a group join occurs for a group that currently 269 has pruned sources. Separate Graft messages must be sent to the 270 appropriate upstream neighbor for each source that has been pruned. 271 Since there would be no way to tell if a Graft message sent upstream 272 was lost or the source simply quit sending traffic, it is necessary 273 to acknowledge each Graft message with a DVMRP Graft Ack message. If 274 an acknowledgment is not received within a Graft Time-out period, the 275 Graft message should be retransmitted. Duplicate Graft Ack messages 276 should simply be ignored. Second, if the prune interval expires, the 277 negative cache entries are removed and the packets will automatically 278 be forwarded again. This is a necessary feature since routers may be 279 restarted and lose all prune state information or new routers may 280 appear. Since these routers will not have prune state associated 281 with the (source, group) pair, they will not realize that a DVMRP 282 Graft message is necessary if a new host joins the group. Therefore, 283 by periodically timing out the prunes and re-flooding the traffic, 284 any new or restarted routers can have their prune state periodically 285 refreshed. 287 3. Detailed Protocol Operation 289 This section contains a detailed description of DVMRP. It covers 290 sending and receiving of DVMRP messages as well as the generation and 291 maintenance of IP Multicast forwarding cache entries. 293 3.1. Protocol Header 295 DVMRP packets are encapsulated in IP datagrams, with an IP protocol 296 number of 2 (IGMP) as specified in the Assigned Numbers RFC. All 297 DVMRP packets use a common protocol header that specifies the IGMP 298 [Fenn96] Packet Type as hexadecimal 0x13 (DVMRP). A diagram of the 299 common protocol header follows: 301 31 23 15 0 302 +---------+---------+--------------------+ 303 | Type | Code | Checksum | 304 |(0x13) | | | 305 +---------+---------+--------------------+ 307 Table 1 - Common Protocol Header 309 The value of the Code field determines the DVMRP packet type. 310 Currently, there are codes allocated for DVMRP protocol message types 311 as well as protocol analysis and troubleshooting packets. The 312 protocol message Codes are: 314 Code Packet Type Description 315 ---------------------------------------------------------------- 316 1 DVMRP Probe for neighbor discovery 317 2 DVMRP Report for unicast route exchange 318 7 DVMRP Prune for pruning multicast delivery trees 319 8 DVMRP Graft for grafting multicast delivery trees 320 9 DVMRP Graft Ack for acknowledging graft messages 321 ---------------------------------------------------------------- 323 Table 2 - Standard Protocol Packet Types 325 There are additional codes used for protocol analysis and 326 troubleshooting. These codes are discussed in Appendix B. The 327 Checksum is the 16-bit one's complement of the one's complement sum 328 of the DVMRP message. The checksum of the DVMRP message should be 329 calculated with the checksum field set to zero. 331 3.2. Probe Messages 333 When a DVMRP router is configured to run on an physical interface, it 334 sends local IP Multicast discovery packets to inform other DVMRP 335 routers that it is operational. These discovery packets are called 336 DVMRP Probes and they serve three purposes. 338 1. Probes provide a mechanism for DVMRP routers to locate each other. 339 The existence of other routers is used for network leaf detection 340 and the list of addresses of the other routers are used in 341 designated router election. In addition, this list of DVMRP 342 neighbors provides a foundation for neighbor prune lists. 344 2. They provide a way for DVMRP routers to determine the capabilities 345 of each other. This may be deduced from the major and minor 346 version numbers in the Probe packet or directly from the 347 capability flags. These flags were first introduced to allow 348 optional protocol features. This specification now mandates the 349 use of Generation IDs and pruning and, therefore, provides no 350 optional capabilities. Other capability flags were used for 351 tracing and troubleshooting and are no longer a part of the actual 352 protocol. These are now defined in a companion document. 354 3. Probes provide a keep-alive function in order to quickly detect 355 neighbor loss. DVMRP probes sent on each multicast capable 356 interface configured for DVMRP SHOULD have an interval of 10 357 seconds. The neighbor time-out interval SHOULD be set at 140 358 seconds. This allows fairly early detection of a lost neighbor yet 359 provides tolerance for busy multicast routers. These values MUST 360 be coordinated between all DVMRP routers on a physical network 361 segment. 363 3.2.1. Router Capabilities 365 In the past, there have been many versions of DVMRP in use with a 366 wide range of capabilities. Practical considerations require a 367 current implementation to interoperate with these older 368 implementations that don't formally specify their capabilities and 369 are not compliant with this specification. For instance, for major 370 versions less than 3, it can be assumed that the neighbor does not 371 support pruning. The formal capability flags were first introduced 372 in an well known implementation (Mrouted version 3.5) in an attempt 373 to take the guess work out which features are supported by a 374 neighbor. These flags are no longer necessary since they are now a 375 required part of the protocol, however, special consideration is 376 necessary to not confuse older implementations that expect these 377 flags to be set. Appendix C was written to assist with these and 378 other backward compatibility issues. Only two of the flags were used 379 for actual protocol operation. The other two assigned flags were used 380 for troubleshooting purposes which are now documented in a separate 381 specification [x]. All of the bits marked "U" in the Table below are 382 unused. They may be defined in the future and MUST be set to 0. Bit 383 positions 1 and 2 MUST be set to 1 for backward compatibility. They 384 were used to specify the PRUNE and GENID bits which are now required 385 features. 387 15 7 M G P L 388 +--------------------------+----+---+---+---+----+---+---+---+ 389 | Reserved | U |U |U | U | U |1 |1 | U | 390 +--------------------------+----+---+---+---+----+---+---+---+ 392 Table 3 - Probe Capability Flags 394 3.2.2. Generation ID 396 If a DVMRP router is restarted, it must immediately exchange unicast 397 routing tables with all of its neighbors. If a neighbor doesn't 398 automatically detect that the neighbor has restarted, then it will 399 not send its entire routing table immediately. Instead, it will 400 spread the updates over an entire routing update interval. In order 401 for the neighbor to detect a router that is restarted, a non- 402 decreasing number is placed in the periodic probe message called the 403 generation ID. If a router detects an increase in the generation ID 404 of a neighbor, it should exchange its entire unicast routing table 405 with the neighbor. A time of day clock provides a good source for a 406 non-decreasing 32 bit integer. 408 3.2.3. Neighbor Addresses 410 As a DVMRP router sees Probe messages from its DVMRP neighbors, it 411 records the neighbor addresses on each interface and places them in 412 the Probe message sent on the particular interface. This allows the 413 neighbor router to know that its probes have been received by the 414 sending router. 416 3.2.4. Probe Packet Format 418 The Probe packet is variable in length depending on the number of 419 neighbor IP addresses included. The length of the IP packet can be 420 used to determine the number of neighbors in the Probe message. The 421 current Major Version is 3. To maintain compatibility with previous 422 versions, implementations of Version 3 must include pruning and 423 grafting of multicast trees. Non-pruning implementations SHOULD NOT 424 be implemented at this time. A Minor Version of 0xFF should be used 425 to indicate compliance with this specification. 427 24 16 8 0 428 +---------+----------+----------+---------+ 429 |Reserved | Capabil- | Minor | Major | 430 | | ities | Version |Version | 431 +---------+----------+----------+---------+ 432 | Generation ID | 433 +-----------------------------------------+ 434 | Neighbor IP Address 1 | 435 +-----------------------------------------+ 436 | Neighbor IP Address 2 | 437 +-----------------------------------------+ 438 | ... | 439 +-----------------------------------------+ 440 | Neighbor IP Address N | 441 +-----------------------------------------+ 443 Table 4 - DVMRP Probe Packet Format 445 3.2.5. Designated Router Election 447 Since it is wasteful to have more than a single router sending IGMP 448 Host Membership Queries on a given physical network, DVMRP provides a 449 method to elect a single router on each physical network as the 450 Designated Querier. Based on the list of neighbors from which DVMRP 451 Probe messages were received, a router will pick the router with the 452 lowest IP address as the designated querier. The router MUST include 453 itself in this list of candidates. 455 3.3. Building Forwarding Cache Entries 457 In order to create optimal multicast delivery trees, IP Multicast was 458 designed to keep separate forwarding cache entries for each (source 459 network, destination group) pair. Because the possible combinations 460 of these is quite large, forwarding cache entries are generated on 461 demand as data arrives at a multicast router. Since the IP forwarding 462 decision is made on a hop by hop basis (as with the unicast case), it 463 is imperative that each multicast router has a consistent view of the 464 reverse path back to the source network. For this reason, DVMRP 465 includes its own unicast routing protocol. 467 3.3.1. Determining the upstream interface 469 When a multicast packet arrives, a DVMRP router will use the internal 470 DVMRP unicast routing table to determine which interface leads back 471 to the source. If the packet did not arrive on that interface, it 472 should be discarded without further processing. Each multicast 473 forwarding entry should cache the upstream interface for a particular 474 source host or source network after looking this up in the DVMRP 475 unicast routing table. 477 3.3.2. Determining the downstream interface list 479 The downstream interface list is built from the remaining list of 480 multicast capable interfaces. Any interfaces designated as leaf 481 networks and do not have members of the particular multicast group 482 can be automatically pruned from list of downstream interfaces. The 483 remaining interfaces will either have downstream DVMRP routers or 484 directly attached group members. These interfaces may be pruned in 485 the future if it is determined that there are no group members 486 anywhere along the entire tree branch. 488 3.4. Unicast Route Exchange 490 It was mentioned earlier that since not all IP routers support IP 491 multicast forwarding, it is necessary to tunnel IP multicast 492 datagrams through these routers. One effect of using these 493 encapsulated tunnels is that IP multicast traffic may not be aligned 494 with IP unicast traffic. This means that a multicast datagram from a 495 particular source can arrive on a different (logical) interface than 496 the expected upstream interface based on traditional unicast routing. 498 The unicast routing information propagated by DVMRP is used 499 exclusively for determining the reverse path back to source of 500 multicast traffic. Tunnels are considered to be distinct interfaces 501 and route reports are sent unicast between tunnel endpoints as though 502 they arrived on the tunnel pseudo interface. The routing information 503 that is propagated by DVMRP contains a list of unicast source 504 networks and an appropriate metric. The metric used is a hop count 505 which is incremented by the cost of the incoming interface metric. 506 Traditionally, physical interfaces use a metric of 1 while the metric 507 of a tunnel interface varies with the distance and bandwidth in the 508 path between the two tunnel endpoints. Users are encouraged to 509 configure tunnels with the same metric in each direction in order to 510 prevent routing loops although the protocol does not strictly enforce 511 this. 513 3.4.1. Route Packing and Ordering 515 Since DVMRP Route Reports may need to refresh several thousand routes 516 each Report interval, routers MUST attempt to spread the routes 517 reported across the whole route update interval. This reduces the 518 chance of synchronized route reports causing routers to become 519 overwhelmed for a few seconds each report interval. Since the route 520 report interval is 60 seconds, it is suggested that the total number 521 routes being updated be split across multiple Route Reports sent at 522 regular intervals. One implementation splits all unicast routes 523 across 6 Report periods sent at 10 seconds intervals. Due to 524 limitations of older implementations of DVMRP, Route Reports should 525 contain source network/mask pairs sorted first by increasing network 526 mask and then by increasing source network within each possible mask 527 value. 529 In order to pack more source networks into a route report, source 530 networks are often represented by less than 4 octets. The number of 531 significant bytes in the mask value is used to determine the number 532 of octets used to represent each source network within that 533 particular mask value. For instance if the mask value of 255.255.0.0 534 is being reported, the source networks would only contain 2 octets 535 each. DVMRP assumes that source networks will never be aggregated 536 into networks whose prefix length is less than 8. Therefore, it does 537 not carry the first octet of the mask in the Route Report since, 538 given this assumption, the first octet will always be 0xFF. This 539 means that the netmask value will always be represented in 3 octets. 540 This method of specifying source network masks is compatible with 541 techniques described in [Rekh93] and [Full93] to group traditional 542 Class C networks into super-nets and to allow different subnets of 543 the same Class A network to be discontinuous. 545 Immediately following each source network is an octet containing the 546 metric advertised to reach the source network. 548 3.4.2. Unicast Route Metrics 550 For each source network reported, a route metric is also contained in 551 the route report. The metric is the sum of the outgoing interface 552 metrics between the router originating the report and the source 553 network. For the purposes of DVMRP, Infinity is defined to be 32. 554 This limits the breadth across the whole DVMRP network and is 555 necessary to place an upper bound on the convergence time of the 556 protocol. 558 As seen in the packet format below, Route Reports do not contain a 559 count of the number of routes reported for each netmask. Instead, the 560 high order bit of the metric is used to signify the last route being 561 reported for a particular mask value. If a metric is read with the 562 high order bit of the 8-bit value set and if the end of the message 563 has not been reached, the next value will be a new netmask to be 564 applied to the subsequent list of routes. This technique is used to 565 prevent wasting space in the Route Report message for a count of 566 unicast source networks for each netmask value contained in the 567 Report. 569 3.4.3. Unicast Route Dependencies 571 In order for pruning to work correctly, each DVMRP router needs to 572 know which downstream routers depend on it for receiving datagrams 573 from particular source networks. Initially, when a new datagram 574 arrives from a particular source/group pair, it is flooded to all 575 downstream interfaces that have DVMRP neighbors who have indicated a 576 dependency on the receiving DVMRP router for that particular source. 577 A downstream interface can only be pruned when it has received Prune 578 messages from each of the dependent routers on that interface. Each 579 downstream router uses a method called Poison Reverse to indicate to 580 the upstream router which source networks it expects to receive from 581 the upstream router. The downstream router indicates this by echoing 582 back the source networks it expects to receive from the upstream 583 router with infinity added to the advertised metric. This means that 584 the legal values for the metric now become between 1 and (2*Infinity 585 -1) or 1 and 63. Values between 1 and 31 indicate reachable unicast 586 source networks. The value Infinity (32)indicates the source network 587 is not reachable. Values between 33 and 63 indicate that the 588 downstream router originating the Report is depending upon the 589 upstream router to provide multicast datagrams from the corresponding 590 source network. 592 3.4.4. Sending Route Reports 594 Full Route Reports MUST be sent out every Route Report Interval. In 595 addition, flash updates CAN be sent between full route reports. 596 Flash updates can reduce the chances of routing loops and black holes 597 occurring when source networks become unreachable through a 598 particular path. Flash updates need only contain the source networks 599 that have changed. It is not necessary to report all of the source 600 networks from a particular mask value when sending an update. 602 3.4.5. Receiving Route Reports 604 After receiving a route report, a check should be made to verify it 605 is from a known neighbor. Neighbors are learned via received Probe 606 messages which also indicate the capabilities of the neighbor. 607 Therefore, route reports from unknown neighbors are discarded. 609 Some older implementations did not sort the routes contained in the 610 update. Therefore, Version 3 implementations MUST be able to handle 611 these reports. 613 If a route is not refreshed within 140 seconds (2 * (Route Report 614 Interval + 10)), then it can be replaced with the next best route to 615 the same source. If, after 200 seconds, the route has not been 616 refreshed, then it should be expired. 618 3.4.6. Route Report Packet Format 620 The format of a sample Route Report Packet is shown in Table 5 below. 621 The packet shown is an example of how the source networks are packed 622 into a Report. The number of octets in each Source Network will vary 623 depending on the mask value. The values below are only an example 624 for clarity and are not intended to represent the format of every 625 Route Report. 627 24 16 8 0 628 +-----------+------------+------------+------------+ 629 | Mask1 | Mask1 | Mask1 | Src | 630 | Octet2 | Octet3 | Octet4 | Net11 | 631 +-----------+------------+------------+------------+ 632 | SrcNet11(cont.)... | Metric11 | Src | 633 | | | Net12 | 634 +------------------------+------------+------------+ 635 | SrcNet12(cont.)... | Metric12 | Mask2 | 636 | | | Octet2 | 637 +-----------+------------+------------+------------+ 638 | Mask2 | Mask2 | SrcNet21 | 639 | Octet3 | Octet4 | | 640 +-----------+------------+------------+------------+ 641 | SrcNet21(cont.)... | Metric21 | Mask3 | 642 | | | Octet2 | 643 +-----------+------------+------------+------------+ 644 | Mask3 | Mask3 | ... | 645 | Octet3 | Octet4 | | 646 +-----------+------------+-------------------------+ 648 Table 5 - Example Route Report Packet Format 650 3.5. Pruning 652 DVMRP is described as a flood and prune multicast routing protocol 653 since datagrams are initially sent out all dependent downstream 654 interfaces and then pruned back to only the downstream interfaces 655 that are on a reverse shortest path to a receiver. Prunes are data 656 driven and are sent in response to receiving unwanted multicast 657 traffic at the leafs of the multicast tree rooted at a particular 658 source network. 660 3.5.1. Leaf Networks 662 Detection of leaf networks is very important to the pruning process. 663 Routers at the end of a source specific multicast delivery tree must 664 detect that there are no further downstream routers. This detection 665 mechanism is covered above in section 3.2 titled DVMRP Probe 666 Messages. If there are no group members present for a particular 667 multicast datagram received, the leaf routers will start the pruning 668 process by pruning their downstream interfaces and sending a prune to 669 the upstream router for that source. 671 3.5.2. Source Networks 673 It is important to note that prunes are specific to a group and 674 source network. A prune sent upstream triggered by traffic received 675 from a particular source applies to all sources on that network. It 676 is not currently possible to prune only one or a subset of hosts on a 677 source network for a particular group. All or none of the sources 678 must be pruned. 680 3.5.3. Receiving a Prune 682 When a prune is received, the following steps should be taken: 684 1. Determine if a Probe has been received from this router recently. 686 2. If not, discard prune since there is no prior state about this 687 neighbor. 689 3. If so, make sure the neighbor is capable of pruning (based on 690 received Probe message). 692 4. Since Prune messages are fixed length, ensure the prune message 693 contains the correct amount of data. 695 5. Extract the source address, group address, and prune time-out 696 values 698 6. If no state exists for the (source, group) pair, then ignore the 699 prune. 701 7. Verify that the prune was received from a dependent neighbor for 702 the source network. If not, discard the prune. 704 8. Determine if a prune is currently active for this (source, group) 705 pair. 707 9. If so, reset the timer to the new time-out value. Otherwise, 708 create state for the new prune and set a timer for the prune 709 lifetime. 711 10. Determine if all dependent downstream routers have now sent 712 prunes. 714 11. If so, a prune should be sent upstream. 716 3.5.4. Sending a Prune 718 When sending a prune upstream, the following steps should be taken: 720 1. Decide if upstream neighbor is capable of receiving prunes. 722 2. If not, then proceed no further. 724 3. Stop any pending Grafts awaiting acknowledgments. 726 4. Determine the prune lifetime. This value should be the minimum of 727 the prune lifetimes remaining from the downstream neighbors and 728 the cache lifetime of the (source, group) pair. 730 5. Form and transmit the packet to the upstream neighbor for the 731 source. 733 3.5.5. Prune Packet Format 735 In addition to the standard IGMP and DVMRP headers, a Prune Packet 736 contains three additional fields: the source host IP address, the 737 destination group IP address, and the Prune Lifetime in seconds. 739 The Prune Lifetime is a derived value based on the current cache 740 entry that is being pruned. It is calculated as the minimum of the 741 cache entry lifetime and the lifetimes of any downstream prunes 742 received for the same cache entry. 744 31 0 745 +----------------------------------+ 746 | Source Address | 747 +----------------------------------+ 748 | Group Address | 749 +----------------------------------+ 750 | Prune Lifetime | 751 +----------------------------------+ 753 Table 6 - Prune Packet Format 755 3.6. Grafting 757 Once a multicast delivery tree has been pruned back, DVMRP Graft 758 messages are necessary to join new receivers onto the multicast tree. 759 Graft messages are sent upstream from the new receiver's first-hop 760 router until a point on the multicast tree is reached. Graft 761 messages are re-originated between adjacent DVMRP routers and are not 762 forwarded by DVMRP routers. Therefore, the first-hop router does not 763 know if the Graft message ever reaches the multicast tree. To remedy 764 this, each Graft message is acknowledged hop by hop. This ensures 765 that the Graft message is not lost somewhere along the path between 766 the receiver's first-hop router and the closest point on the 767 multicast delivery tree. 769 3.6.1. Grafting All Sources 771 It is important to realize that prunes are source specific and are 772 sent up different trees for each source. Grafts are sent in response 773 to a new Group Member which is not source specific. Therefore, 774 separate Graft messages must be sent to the appropriate upstream 775 routers to counteract each previous source specific prune that was 776 sent. 778 3.6.2. Sending a Graft 779 As mentioned above, a Graft message sent to the upstream DVMRP router 780 should be acknowledged hop by hop guaranteeing end-to-end delivery. 781 If a Graft Acknowledgment is not received within a Graft 782 Retransmission Time-out period, the Graft should be resent to the 783 upstream router. The time-out period is fixed at 5 seconds. In order 784 to send a Graft message, the following steps should be taken: 786 1. Verify a forwarding cache entry exists for the (source, group) 787 pair and that a prune exists for the cache entry. 789 2. Verify that the upstream router is capable of receiving prunes 790 (and therefore grafts). 792 3. Add the graft to the retransmission timer list awaiting an 793 acknowledgment. 795 4. Formulate and transmit the Graft packet. 797 3.6.3. Receiving a Graft 799 The actions taken when a Graft is received depends on the state in 800 the receiving router for the (source, group) pair in the received 801 Graft message. If the receiving router has prune state for the 802 (source, group) pair, then it must acknowledge the received graft and 803 send a subsequent graft to its upstream router. If the receiving 804 router has some pruned downstream interfaces but has not sent a prune 805 upstream, then the receiving interface can simply be added to the 806 list of downstream interfaces in the forwarding cache. A Graft 807 Acknowledgment must also be sent back to the source of the Graft 808 message. If the receiving router has no state at all for the 809 (source, group) pair, then datagrams arriving for the (source, group) 810 pair should automatically be flooded when they arrive. A Graft 811 Acknowledgment must be sent to the source of the Graft message. If a 812 Graft message is received from an unknown neighbor, it should be 813 discarded. 815 3.6.4. Graft Packet Format 817 The format of a Graft packet is show below: 819 31 0 820 +----------------------------------+ 821 | Source Address | 822 +----------------------------------+ 823 | Group Address | 824 +----------------------------------+ 826 Table 7 - Graft Packet Format 828 3.6.5. Sending a Graft Acknowledgment 830 A Graft Acknowledgment packet is sent to a downstream neighbor in 831 response to receiving a Graft message. Grafts received from unknown 832 neighbors should be discarded but all other correctly formatted Graft 833 messages should be acknowledged. This is true even if no other action 834 is taken in response to receiving the Graft to prevent the source 835 from continually re-transmitting the Graft message. The Graft 836 Acknowledgment packet is identical to the Graft packet except that 837 the DVMRP code in the common header is set to Graft Ack. This allows 838 the receiver of the Graft Ack message to correctly identify which 839 Graft was acknowledged and stop the appropriate retransmission timer. 841 3.6.6. Receiving a Graft Acknowledgment 843 When a Graft Acknowledgment is received, the (source, group) pair in 844 the packet can be used to determine if a Graft was sent to this 845 particular upstream router. If no Graft was sent, the Graft Ack can 846 simply be ignored. If a Graft was sent, and the acknowledgment has 847 come from the correct upstream router, then it has been successfully 848 received and the retransmission timer for the Graft can be stopped. 850 3.6.7. Graft Acknowledgment Packet Format 852 The format of a Graft Ack packet (which is identical to that of a 853 Graft packet is show below: 855 31 0 856 +----------------------------------+ 857 | Source Address | 858 +----------------------------------+ 859 | Group Address | 860 +----------------------------------+ 862 Table 8 - Graft Ack Packet Format 864 3.7. Interfaces 866 Interfaces running DVMRP will either be multicast capable physical 867 interfaces or encapsulated tunnel pseudo-interfaces. Physical 868 interfaces may either be multi-access networks or point-to-point 869 networks. Tunnel interfaces are used when there are non-multicast 870 capable routers between DVMRP neighbors. Multicast data traffic is 871 sent between tunnel endpoints using IP-IP encapsulation. The unicast 872 IP addresses of the tunnel endpoints are used as the source and 873 destination IP addresses in the outer IP header. The inner IP header 874 remains unchanged from the original data packet. 876 Since DVMRP Protocol messages are not encapsulated when sent between 877 tunnel endpoints, they must always be sent directly to the unicast 878 address of the tunneled neighbor. 880 4. Security Considerations 882 Security considerations will be discussed in an upcoming revision of 883 this document. 885 5. References 887 [Deer90] Deering, S., Cheriton, D., "Multicast Routing in Datagram 888 Internetworks and Extended LANs", ACM Transactions on 889 Computer Systems, Vol. 8, No. 2, May 1990, Pages 85-110. 891 [Wait88] Waitzman, D., Partridge, C., Deering, S., "Distance Vector 892 Multicast Routing Protocol", RFC 1075, November 1988. 894 [Perk96] Perkins, C., IP Encapsulation within IP, Work in Progress, 895 May 1996. 897 [Deer89] Deering, S., "Host Extensions for IP Multicasting", RFC 898 1112, August 1989. 900 [Fenn96] Fenner, W., "Internet Group Management Protocol, Version 901 2", Work In Progress, February 1996. 903 [Rekh93] Rekhter, Y., and T. Li, "An Architecture for IP Address 904 Allocation with CIDR", RFC 1518, September 1993. 906 [Full93] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 907 Inter-Domain Routing (CIDR): an Address Assignment and 908 Aggregation Strategy", RFC 1519, September 1993. 910 6. Author's Address 912 Thomas Pusateri 913 Juniper Networks, Inc. 914 101 University Ave. 915 Suite 240 916 Palo Alto, CA 94301 918 Phone: (919) 676-9341 919 EMail: pusateri@jnx.com 921 7. Acknowledgments 923 The author would like to acknowledge the original designers of the 924 protocol, Steve Deering, Craig Partridge, and David Waitzman. 925 Version 3 of the protocol would not have been possible without the 926 work of Ajit Thyagarajan as well as the continued development efforts 927 of Bill Fenner. Credit also goes to Dave LeRoy and Danny Mitzel for 928 the careful review of this document. 930 8. Appendix A - Constants & Configurable Parameters 932 The following table provides a summary of the DVMRP timing 933 parameters: 935 Parameter Value (seconds) 936 ---------------------------------------------- 937 Probe Interval 10 938 Neighbor Time-out Interval 140 939 Route Report Interval 60 940 Route Replacement Time 140 941 Route Expiration Time 200 942 Prune Lifetime variable (< 300) 943 Graft Retransmission Time 5 944 ---------------------------------------------- 946 Table 9 - Parameter Summary 948 9. Appendix B - Tracing and Troubleshooting support 950 There are several packet types used to gather DVMRP specific 951 information. They are generally used for diagnosing problems or 952 gathering topology information. The first two messages are now 953 obsoleted and should not be used. The remaining two messages provide 954 a request/response mechanism to determine the versions and 955 capabilities of a particular DVMRP router. 957 Code Packet Type Description 958 ----------------------------------------------------------- 959 3 DVMRP Ask Neighbors Obsolete 960 4 DVMRP Neighbors Obsolete 961 5 DVMRP Ask Neighbors 2 Request Neighbor List 962 6 DVMRP Neighbors 2 Respond with Neighbor List 963 ----------------------------------------------------------- 965 Table 10 - Debugging Packet Types 967 9.1. DVMRP Ask Neighbors2 969 The Ask Neighbors2 packet is a unicast request packet directed at a 970 DVMRP router. The destination should respond with a unicast 971 Neighbors2 message back to the sender of the Ask Neighbors2 message. 973 31 23 15 0 974 +---------+---------+--------------------+ 975 | Type | Code | Checksum | 976 |(0x13) | (0x5) | | 977 +---------+---------+----------+---------+ 978 | Reserved | Minor | Major | 979 | | Version |Version | 980 +-------------------+----------+---------+ 982 Table 11 - Ask Neighbors 2 Packet Format 984 9.2. DVMRP Neighbors2 986 The format of a Neighbors2 response packet is shown below. This is 987 sent as a unicast message back to the sender of an Ask Neighbors2 988 message. There is a common header at the top followed by the routers 989 capabilities. One or more sections follow that contain an entry for 990 each logical interface. The interface parameters are listed along 991 with a variable list of neighbors learned on each interface. 993 31 23 15 0 994 +-----------+--------------+--------------------------+ 995 | Type | Code | Checksum | 996 | (0x13) | (0x6) | | 997 +-----------+--------------+------------+-------------+ 998 | Reserved | Capabilities | Minor | Major | 999 | | | Version | Version | 1000 +-----------+--------------+------------+-------------+ 1001 | | 1002 | Local Addr 1 | 1003 +-----------+--------------+------------+-------------+ 1004 | | | | | 1005 | Metric 1 | Threshold 1 | Flags 1 | Nbr Count 1 | 1006 +-----------+--------------+------------+-------------+ 1007 | | 1008 | Nbr 1 | 1009 +-----------------------------------------------------+ 1010 | | 1011 | ... | 1012 +-----------------------------------------------------+ 1013 | | 1014 | Nbr m | 1015 +-----------------------------------------------------+ 1016 | | 1017 | Local Addr N | 1018 +-----------+--------------+------------+-------------+ 1019 | | | | | 1020 | Metric N | Threshold N | Flags N | Nbr Count N | 1021 +-----------+--------------+------------+-------------+ 1022 | | 1023 | Nbr 1 | 1024 +-----------------------------------------------------+ 1025 | | 1026 | ... | 1027 +-----------------------------------------------------+ 1028 | | 1029 | Nbr k | 1030 +-----------------------------------------------------+ 1032 Table 12 - Neighbors 2 Packet Format 1034 The capabilities associated with a local interface are defined as 1036 follows: 1038 Bit Flag Description 1039 --------------------------------------------------- 1041 0 Leaf This is a leaf interface 1043 1 Prune This router understands pruning 1045 2 GenID This router sends Generation IDs 1047 3 Mtrace This router handles Mtrace requests 1048 --------------------------------------------------- 1050 The flags associated with a particular neighbor are: 1052 Bit Flag Description 1053 -------------------------------------------------------- 1055 0 Tunnel Neighbor reached via tunnel 1057 1 Source Route Tunnel uses IP source routing 1059 2 PIM Neighbor is a PIM router 1061 3 Down Operational status down 1063 4 Disabled Administrative status down 1065 5 Querier Elected IGMP querier for network 1067 6 Leaf Neighbor has no downstream routers 1068 -------------------------------------------------------- 1070 10. Appendix C - Version Compatibility 1072 There have been two previous major versions of DVMRP with 1073 implementations still in circulation. If the receipt of a Probe 1074 message reveals a major version of 1 or 2, then it can be assumed 1075 that this neighbor does not support pruning or the use of the 1076 Generation ID in the Probe message. However, since these older 1077 implementations are known to safely ignore the Generation ID and 1078 neighbor information in the Probe packet, it is not necessary to 1079 send specially formatted Probe packets to these neighbors. 1081 There were two minor versions (1 and 2) of major version 3 that 1082 did support pruning but did not support the Generation ID or 1083 capability flags. These special cases will have to be accounted 1084 for. 1086 Any other minor versions of major version 3 conform to this 1087 specification. 1089 In addition, cisco Systems is known to use their software major 1090 and minor release number as the DVMRP major and minor version 1091 number. These will typically be 10 or 11 for the major version 1092 number. These implementations do support pruning but do not 1093 support the Generation ID in the Probe message. 1095 Table of Contents 1097 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 1098 1.1. Reverse Path Multicasting . . . . . . . . . . . . . . 2 1099 1.2. IP-IP Tunnels . . . . . . . . . . . . . . . . . . . . 2 1100 1.3. Document Overview . . . . . . . . . . . . . . . . . . 2 1101 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 3 1102 2.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . 3 1103 2.2. Source Location . . . . . . . . . . . . . . . . . . . 3 1104 2.3. Dependent Downstream Routers . . . . . . . . . . . . . 4 1105 2.4. Building Multicast Trees . . . . . . . . . . . . . . . 5 1106 2.5. Pruning Multicast Trees . . . . . . . . . . . . . . . 6 1107 2.6. Grafting Multicast Trees . . . . . . . . . . . . . . . 7 1108 3. Detailed Protocol Operation . . . . . . . . . . . . . . . . 7 1109 3.1. Protocol Header . . . . . . . . . . . . . . . . . . . 8 1110 3.2. Probe Messages . . . . . . . . . . . . . . . . . . . . 9 1111 3.3. Building Forwarding Cache Entries . . . . . . . . . . 12 1112 3.4. Unicast Route Exchange . . . . . . . . . . . . . . . . 12 1113 3.5. Pruning . . . . . . . . . . . . . . . . . . . . . . . 16 1114 3.6. Grafting . . . . . . . . . . . . . . . . . . . . . . . 19 1115 3.7. Interfaces . . . . . . . . . . . . . . . . . . . . . . 22 1116 4. Security Considerations . . . . . . . . . . . . . . . . . . 22 1117 5. References . . . . . . . . . . . . . . . . . . . . . . . . 22 1118 6. Author's Address . . . . . . . . . . . . . . . . . . . . . 23 1119 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 1120 8. Appendix A - Constants & Configurable Parameters . . . . . 23 1121 9. Appendix B - Tracing and Troubleshooting support . . . . . 24 1122 9.1. DVMRP Ask Neighbors2 . . . . . . . . . . . . . . . . . 24 1123 9.2. DVMRP Neighbors2 . . . . . . . . . . . . . . . . . . . 25 1124 10. Appendix C - Version Compatibility . . . . . . . . . . . . 28