idnits 2.17.1 draft-ietf-idmr-dvmrp-v3-02.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 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 ([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. ** 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 362: '...igured for DVMRP SHOULD have an interv...' RFC 2119 keyword, line 363: '...time-out interval SHOULD be set at 140...' RFC 2119 keyword, line 365: '...y multicast routers. These values MUST...' RFC 2119 keyword, line 388: '...n the future and MUST be set to 0. Bit...' RFC 2119 keyword, line 389: '...ositions 1 and 2 MUST be set to 1 for ...' (4 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 324 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 (July 1996) is 10146 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) ** Obsolete normative reference: RFC 1825 (ref. 'Atk95a') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (ref. 'Atk95b') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. 'Atk95c') (Obsoleted by RFC 2406) -- Possible downref: Non-RFC (?) normative reference: ref. 'Deer90' -- Possible downref: Non-RFC (?) normative reference: ref. 'Fenn96' ** Obsolete normative reference: RFC 1519 (ref. 'Full93') (Obsoleted by RFC 4632) -- Possible downref: Non-RFC (?) normative reference: ref. 'Perk96' ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. 'Rekh93') ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. 'Wait88') Summary: 17 errors (**), 0 flaws (~~), 5 warnings (==), 6 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 July 1996 5 draft-ietf-idmr-dvmrp-v3-02 Expires: January 1997 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 [Wait88]. 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 fields are transmitted in Network Byte Order. DVMRP packets use a 298 common protocol header that specifies the IGMP [Fenn96] Packet Type 299 as hexadecimal 0x13 (DVMRP). A diagram of the common protocol header 300 follows: 302 0 8 16 23 303 +---------+----------+--------------------+ 304 | Type | Code | Checksum | 305 | (0x13) | | | 306 +---------+----------+----------+---------+ 307 |Reserved | Capabil- | Minor | Major | 308 | | ities | Version |Version | 309 +---------+----------+----------+---------+ 311 Figure 1 - Common Protocol Header 313 The value of the Code field determines the DVMRP packet type. 314 Currently, there are codes allocated for DVMRP protocol message types 315 as well as protocol analysis and troubleshooting packets. The 316 protocol message Codes are: 318 Code Packet Type Description 319 ---------------------------------------------------------------- 320 1 DVMRP Probe for neighbor discovery 321 2 DVMRP Report for unicast route exchange 322 7 DVMRP Prune for pruning multicast delivery trees 323 8 DVMRP Graft for grafting multicast delivery trees 324 9 DVMRP Graft Ack for acknowledging graft messages 325 ---------------------------------------------------------------- 327 Table 1 - Standard Protocol Packet Types 329 There are additional codes used for protocol analysis and 330 troubleshooting. These codes are discussed in Appendix B. The 331 Checksum is the 16-bit one's complement of the one's complement sum 332 of the DVMRP message. The checksum of the DVMRP message should be 333 calculated with the checksum field set to zero. 335 3.2. Probe Messages 337 When a DVMRP router is configured to run on an physical interface, it 338 sends local IP Multicast discovery packets to inform other DVMRP 339 routers that it is operational. These discovery packets are called 340 DVMRP Probes and they serve three purposes. 342 1. Probes provide a mechanism for DVMRP routers to locate each other. 343 DVMRP sends a list of detected neighbors in the Probe message. 344 This list of DVMRP neighbors provides a foundation for neighbor 345 prune list. If no DVMRP neighbors are found, the network is 346 considered to be a leaf network. A DVMRP router should discard all 347 other protocol packets from a neighbor until it seen its own 348 address in the neighbors Probe list. 350 2. They provide a way for DVMRP routers to determine the capabilities 351 of each other. This may be deduced from the major and minor 352 version numbers in the Probe packet or directly from the 353 capability flags. These flags were first introduced to allow 354 optional protocol features. This specification now mandates the 355 use of Generation IDs and pruning and, therefore, provides no 356 optional capabilities. Other capability flags were used for 357 tracing and troubleshooting and are no longer a part of the actual 358 protocol. These are now defined in an appendix. 360 3. Probes provide a keep-alive function in order to quickly detect 361 neighbor loss. DVMRP probes sent on each multicast capable 362 interface configured for DVMRP SHOULD have an interval of 10 363 seconds. The neighbor time-out interval SHOULD be set at 140 364 seconds. This allows fairly early detection of a lost neighbor yet 365 provides tolerance for busy multicast routers. These values MUST 366 be coordinated between all DVMRP routers on a physical network 367 segment. 369 3.2.1. Router Capabilities 371 In the past, there have been many versions of DVMRP in use with a 372 wide range of capabilities. Practical considerations require a 373 current implementation to interoperate with these older 374 implementations that don't formally specify their capabilities and 375 are not compliant with this specification. For instance, for major 376 versions less than 3, it can be assumed that the neighbor does not 377 support pruning. The formal capability flags were first introduced 378 in an well known implementation (Mrouted version 3.5) in an attempt 379 to take the guess work out which features are supported by a 380 neighbor. These flags are no longer necessary since they are now a 381 required part of the protocol, however, special consideration is 382 necessary to not confuse older implementations that expect these 383 flags to be set. Appendix C was written to assist with these and 384 other backward compatibility issues. Only two of the flags were used 385 for actual protocol operation. The other two assigned flags were used 386 for troubleshooting purposes which are now documented in a separate 387 specification [x]. All of the bits marked "U" in the Figure below are 388 unused. They may be defined in the future and MUST be set to 0. Bit 389 positions 1 and 2 MUST be set to 1 for backward compatibility. They 390 were used to specify the PRUNE and GENID bits which are now required 391 features. 393 0 8 9 10 M G P L 394 +--------------------------+----+----+----+----+----+----+----+----+ 395 | Reserved | U | U | U | U | U | 1 | 1 | U | 396 +--------------------------+----+----+----+----+----+----+----+----+ 398 Figure 2 - Probe Capability Flags 400 3.2.2. Generation ID 402 If a DVMRP router is restarted, it must immediately exchange unicast 403 routing tables with all of its neighbors. If a neighbor doesn't 404 automatically detect that the neighbor has restarted, then it will 405 not send its entire routing table immediately. Instead, it will 406 spread the updates over an entire routing update interval. In order 407 for the neighbor to detect a router that is restarted, a non- 408 decreasing number is placed in the periodic probe message called the 409 generation ID. If a router detects an increase in the generation ID 410 of a neighbor, it should exchange its entire unicast routing table 411 with the neighbor. A time of day clock provides a good source for a 412 non-decreasing 32 bit integer. 414 3.2.3. Neighbor Addresses 416 As a DVMRP router sees Probe messages from its DVMRP neighbors, it 417 records the neighbor addresses on each interface and places them in 418 the Probe message sent on the particular interface. This allows the 419 neighbor router to know that its probes have been received by the 420 sending router. 422 3.2.4. Probe Packet Format 424 The Probe packet is variable in length depending on the number of 425 neighbor IP addresses included. The length of the IP packet can be 426 used to determine the number of neighbors in the Probe message. The 427 current Major Version is 3. To maintain compatibility with previous 428 versions, implementations of Version 3 must include pruning and 429 grafting of multicast trees. Non-pruning implementations SHOULD NOT 430 be implemented at this time. A Minor Version of 0xFF should be used 431 to indicate compliance with this specification. 433 7 15 23 31 434 +---------+--------------+--------------------+ 435 | Type | Code | Checksum | 436 | (0x13) | (0x1) | | 437 +---------+--------------+----------+---------+ 438 |Reserved | Capabilities | Minor | Major | 439 +---------+--------------+----------+---------+ 440 | Generation ID | 441 +---------------------------------------------+ 442 | Neighbor IP Address 1 | 443 +---------------------------------------------+ 444 | Neighbor IP Address 2 | 445 +---------------------------------------------+ 446 | ... | 447 +---------------------------------------------+ 448 | Neighbor IP Address N | 449 +---------------------------------------------+ 451 Figure 3 - DVMRP Probe Packet Format 453 3.2.5. Designated Router Election 455 Since it is wasteful to have more than a single router sending IGMP 456 Host Membership Queries on a given physical network, a single router 457 on each physical network is elected as the Designated Querier. This 458 election used to be a part of DVMRP. However, this is now handled as 459 a part of the IGMP protocol in version 2 and later. Therefore, DVMRP 460 Version 3 requires the use of IGMP Version 2 or later specifying that 461 the Designated Querier election is performed as a part of IGMP. 463 3.3. Building Forwarding Cache Entries 465 In order to create optimal multicast delivery trees, IP Multicast was 466 designed to keep separate forwarding cache entries for each (source 467 network, destination group) pair. Because the possible combinations 468 of these is quite large, forwarding cache entries are generated on 469 demand as data arrives at a multicast router. Since the IP forwarding 470 decision is made on a hop by hop basis (as with the unicast case), it 471 is imperative that each multicast router has a consistent view of the 472 reverse path back to the source network. For this reason, DVMRP 473 includes its own unicast routing protocol. 475 3.3.1. Determining the upstream interface 477 When a multicast packet arrives, a DVMRP router will use the internal 478 DVMRP unicast routing table to determine which interface leads back 479 to the source. If the packet did not arrive on that interface, it 480 should be discarded without further processing. Each multicast 481 forwarding entry should cache the upstream interface for a particular 482 source host or source network after looking this up in the DVMRP 483 unicast routing table. 485 3.3.2. Determining the downstream interface list 487 The downstream interface list is built from the remaining list of 488 multicast capable interfaces. Any interfaces designated as leaf 489 networks and do not have members of the particular multicast group 490 can be automatically pruned from list of downstream interfaces. The 491 remaining interfaces will either have downstream DVMRP routers or 492 directly attached group members. These interfaces may be pruned in 493 the future if it is determined that there are no group members 494 anywhere along the entire tree branch. 496 3.4. Unicast Route Exchange 498 It was mentioned earlier that since not all IP routers support IP 499 multicast forwarding, it is necessary to tunnel IP multicast 500 datagrams through these routers. One effect of using these 501 encapsulated tunnels is that IP multicast traffic may not be aligned 502 with IP unicast traffic. This means that a multicast datagram from a 503 particular source can arrive on a different (logical) interface than 504 the expected upstream interface based on traditional unicast routing. 506 The unicast routing information propagated by DVMRP is used 507 exclusively for determining the reverse path back to source of 508 multicast traffic. Tunnels are considered to be distinct interfaces 509 and route reports are sent unicast between tunnel endpoints as though 510 they arrived on the tunnel pseudo interface. The routing information 511 that is propagated by DVMRP contains a list of unicast source 512 networks and an appropriate metric. The metric used is a hop count 513 which is incremented by the cost of the incoming interface metric. 514 Traditionally, physical interfaces use a metric of 1 while the metric 515 of a tunnel interface varies with the distance and bandwidth in the 516 path between the two tunnel endpoints. Users are encouraged to 517 configure tunnels with the same metric in each direction in order to 518 prevent routing loops although the protocol does not strictly enforce 519 this. 521 3.4.1. Route Packing and Ordering 523 Since DVMRP Route Reports may need to refresh several thousand routes 524 each Report interval, routers MUST attempt to spread the routes 525 reported across the whole route update interval. This reduces the 526 chance of synchronized route reports causing routers to become 527 overwhelmed for a few seconds each report interval. Since the route 528 report interval is 60 seconds, it is suggested that the total number 529 routes being updated be split across multiple Route Reports sent at 530 regular intervals. One implementation splits all unicast routes 531 across 6 Report periods sent at 10 seconds intervals. Due to 532 limitations of older implementations of DVMRP, Route Reports should 533 contain source network/mask pairs sorted first by increasing network 534 mask and then by increasing source network within each possible mask 535 value. 537 In order to pack more source networks into a route report, source 538 networks are often represented by less than 4 octets. The number of 539 significant bytes in the mask value is used to determine the number 540 of octets used to represent each source network within that 541 particular mask value. For instance if the mask value of 255.255.0.0 542 is being reported, the source networks would only contain 2 octets 543 each. DVMRP assumes that source networks will never be aggregated 544 into networks whose prefix length is less than 8. Therefore, it does 545 not carry the first octet of the mask in the Route Report since, 546 given this assumption, the first octet will always be 0xFF. This 547 means that the netmask value will always be represented in 3 octets. 548 This method of specifying source network masks is compatible with 549 techniques described in [Rekh93] and [Full93] to group traditional 550 Class C networks into super-nets and to allow different subnets of 551 the same Class A network to be discontinuous. 553 Immediately following each source network is an octet containing the 554 metric advertised to reach the source network. 556 3.4.2. Unicast Route Metrics 558 For each source network reported, a route metric is also contained in 559 the route report. The metric is the sum of the outgoing interface 560 metrics between the router originating the report and the source 561 network. For the purposes of DVMRP, Infinity is defined to be 32. 562 This limits the breadth across the whole DVMRP network and is 563 necessary to place an upper bound on the convergence time of the 564 protocol. 566 As seen in the packet format below, Route Reports do not contain a 567 count of the number of routes reported for each netmask. Instead, the 568 high order bit of the metric is used to signify the last route being 569 reported for a particular mask value. If a metric is read with the 570 high order bit of the 8-bit value set and if the end of the message 571 has not been reached, the next value will be a new netmask to be 572 applied to the subsequent list of routes. This technique is used to 573 prevent wasting space in the Route Report message for a count of 574 unicast source networks for each netmask value contained in the 575 Report. 577 3.4.3. Unicast Route Dependencies 579 In order for pruning to work correctly, each DVMRP router needs to 580 know which downstream routers depend on it for receiving datagrams 581 from particular source networks. Initially, when a new datagram 582 arrives from a particular source/group pair, it is flooded to all 583 downstream interfaces that have DVMRP neighbors who have indicated a 584 dependency on the receiving DVMRP router for that particular source. 585 A downstream interface can only be pruned when it has received Prune 586 messages from each of the dependent routers on that interface. Each 587 downstream router uses a method called Poison Reverse to indicate to 588 the upstream router which source networks it expects to receive from 589 the upstream router. The downstream router indicates this by echoing 590 back the source networks it expects to receive from the upstream 591 router with infinity added to the advertised metric. This means that 592 the legal values for the metric now become between 1 and (2*Infinity 593 -1) or 1 and 63. Values between 1 and 31 indicate reachable unicast 594 source networks. The value Infinity (32)indicates the source network 595 is not reachable. Values between 33 and 63 indicate that the 596 downstream router originating the Report is depending upon the 597 upstream router to provide multicast datagrams from the corresponding 598 source network. 600 3.4.4. Sending Route Reports 602 Full Route Reports MUST be sent out every Route Report Interval. In 603 addition, flash updates CAN be sent between full route reports. 604 Flash updates can reduce the chances of routing loops and black holes 605 occurring when source networks become unreachable through a 606 particular path. Flash updates need only contain the source networks 607 that have changed. It is not necessary to report all of the source 608 networks from a particular mask value when sending an update. 610 A DVMRP router should not send a Route Report to a neighbor until it 611 has seen its own address in the neighbors Probe neighbor list. 613 3.4.5. Receiving Route Reports 615 After receiving a route report, a check should be made to verify it 616 is from a known neighbor. Neighbors are learned via received Probe 617 messages which also indicate the capabilities of the neighbor. 618 Therefore, route reports from unknown neighbors are discarded. 620 Some older implementations did not sort the routes contained in the 621 update. Therefore, Version 3 implementations MUST be able to handle 622 these reports. 624 If a route is not refreshed within 140 seconds (2 * (Route Report 625 Interval + 10)), then it can be replaced with the next best route to 626 the same source. If, after 200 seconds, the route has not been 627 refreshed, then it should be expired. 629 3.4.6. Route Report Packet Format 631 The format of a sample Route Report Packet is shown in Figure 4 632 below. The packet shown is an example of how the source networks are 633 packed into a Report. The number of octets in each Source Network 634 will vary depending on the mask value. The values below are only an 635 example for clarity and are not intended to represent the format of 636 every Route Report. 638 7 15 23 31 639 +-----------+------------+-------------------------+ 640 | Type | Code | Checksum | 641 | (0x13) | (0x2) | | 642 +-----------+------------+------------+------------+ 643 | Reserved | Capabil- | Minor | Major | 644 | | ities | Version | Version | 645 +-----------+------------+------------+------------+ 646 | Mask1 | Mask1 | Mask1 | Src | 647 | Octet2 | Octet3 | Octet4 | Net11 | 648 +-----------+------------+------------+------------+ 649 | SrcNet11(cont.)... | Metric11 | Src | 650 | | | Net12 | 651 +------------------------+------------+------------+ 652 | SrcNet12(cont.)... | Metric12 | Mask2 | 653 | | | Octet2 | 654 +-----------+------------+------------+------------+ 655 | Mask2 | Mask2 | SrcNet21 | 656 | Octet3 | Octet4 | | 657 +-----------+------------+------------+------------+ 658 | SrcNet21(cont.)... | Metric21 | Mask3 | 659 | | | Octet2 | 660 +-----------+------------+------------+------------+ 661 | Mask3 | Mask3 | ... | 662 | Octet3 | Octet4 | | 663 +-----------+------------+-------------------------+ 665 Figure 4 - Example Route Report Packet Format 667 3.5. Pruning 669 DVMRP is described as a flood and prune multicast routing protocol 670 since datagrams are initially sent out all dependent downstream 671 interfaces and then pruned back to only the downstream interfaces 672 that are on a reverse shortest path to a receiver. Prunes are data 673 driven and are sent in response to receiving unwanted multicast 674 traffic at the leafs of the multicast tree rooted at a particular 675 source network. 677 3.5.1. Leaf Networks 679 Detection of leaf networks is very important to the pruning process. 680 Routers at the end of a source specific multicast delivery tree must 681 detect that there are no further downstream routers. This detection 682 mechanism is covered above in section 3.2 titled DVMRP Probe 683 Messages. If there are no group members present for a particular 684 multicast datagram received, the leaf routers will start the pruning 685 process by pruning their downstream interfaces and sending a prune to 686 the upstream router for that source. 688 3.5.2. Source Networks 690 It is important to note that prunes are specific to a group and 691 source network. A prune sent upstream triggered by traffic received 692 from a particular source applies to all sources on that network. It 693 is not currently possible to prune only one or a subset of hosts on a 694 source network for a particular group. All or none of the sources 695 must be pruned. 697 3.5.3. Receiving a Prune 699 When a prune is received, the following steps should be taken: 701 1. Determine if a Probe has been received from this router recently. 703 2. If not, discard prune since there is no prior state about this 704 neighbor. 706 3. If so, make sure the neighbor is capable of pruning (based on 707 received Probe message). 709 4. Since Prune messages are fixed length, ensure the prune message 710 contains the correct amount of data. 712 5. Extract the source address, group address, and prune time-out 713 values 715 6. If no state exists for the (source, group) pair, then ignore the 716 prune. 718 7. Verify that the prune was received from a dependent neighbor for 719 the source network. If not, discard the prune. 721 8. Determine if a prune is currently active from the same dependent 722 neighbor for this (source, group) pair. 724 9. If so, reset the timer to the new time-out value. Otherwise, 725 create state for the new prune and set a timer for the prune 726 lifetime. 728 10. Determine if all dependent downstream routers on the interface 729 from which the prune was received have now sent prunes. 731 11. If so, then determine if there are group members active on the 732 interface. 734 12. If no group members are found, then prune the interface. 736 13. If all downstream interfaces have now been pruned, send a prune 737 to the RPF neighbor on the upstream interface. 739 3.5.4. Sending a Prune 740 When sending a prune upstream, the following steps should be taken: 742 1. Decide if upstream neighbor is capable of receiving prunes. 744 2. If not, then proceed no further. 746 3. Stop any pending Grafts awaiting acknowledgments. 748 4. Determine the prune lifetime. This value should be the minimum of 749 the prune lifetimes remaining from the downstream neighbors and 750 the cache lifetime of the (source, group) pair. 752 5. Form and transmit the packet to the upstream neighbor for the 753 source. 755 3.5.5. Prune Packet Format 757 In addition to the standard IGMP and DVMRP headers, a Prune Packet 758 contains three additional fields: the source host IP address, the 759 destination group IP address, and the Prune Lifetime in seconds. 761 The Prune Lifetime is a derived value based on the current cache 762 entry that is being pruned. It is calculated as the minimum of the 763 cache entry lifetime and the lifetimes of any downstream prunes 764 received for the same cache entry. 766 7 15 23 31 767 +-------------+--------------+-----------------------------+ 768 | Type | Code | Checksum | 769 | (0x13) | (0x7) | | 770 +-------------+--------------+--------------+--------------+ 771 | Reserved | Capabilities | Minor | Major | 772 +-------------+--------------+--------------+--------------+ 773 | Source Address | 774 +----------------------------------------------------------+ 775 | Group Address | 776 +----------------------------------------------------------+ 777 | Prune Lifetime | 778 +----------------------------------------------------------+ 780 Figure 5 - Prune Packet Format 782 3.6. Grafting 784 Once a multicast delivery tree has been pruned back, DVMRP Graft 785 messages are necessary to join new receivers onto the multicast tree. 786 Graft messages are sent upstream from the new receiver's first-hop 787 router until a point on the multicast tree is reached. Graft 788 messages are re-originated between adjacent DVMRP routers and are not 789 forwarded by DVMRP routers. Therefore, the first-hop router does not 790 know if the Graft message ever reaches the multicast tree. To remedy 791 this, each Graft message is acknowledged hop by hop. This ensures 792 that the Graft message is not lost somewhere along the path between 793 the receiver's first-hop router and the closest point on the 794 multicast delivery tree. 796 3.6.1. Grafting All Sources 798 It is important to realize that prunes are source specific and are 799 sent up different trees for each source. Grafts are sent in response 800 to a new Group Member which is not source specific. Therefore, 801 separate Graft messages must be sent to the appropriate upstream 802 routers to counteract each previous source specific prune that was 803 sent. 805 3.6.2. Sending a Graft 807 As mentioned above, a Graft message sent to the upstream DVMRP router 808 should be acknowledged hop by hop guaranteeing end-to-end delivery. 809 If a Graft Acknowledgment is not received within the Graft 810 Retransmission Time-out period, the Graft should be resent to the 811 upstream router. The initial retransmission period is 5 seconds. A 812 binary exponential backoff policy is used on subsequent 813 retransmissions. In order to send a Graft message, the following 814 steps should be taken: 816 1. Verify a forwarding cache entry exists for the (source, group) 817 pair and that a prune exists for the cache entry. 819 2. Verify that the upstream router is capable of receiving prunes 820 (and therefore grafts). 822 3. Add the graft to the retransmission timer list awaiting an 823 acknowledgment. 825 4. Formulate and transmit the Graft packet. 827 3.6.3. Receiving a Graft 829 The actions taken when a Graft is received depends on the state in 830 the receiving router for the (source, group) pair in the received 831 Graft message. If the receiving router has prune state for the 832 (source, group) pair, then it must acknowledge the received graft and 833 send a subsequent graft to its upstream router. If the receiving 834 router has some pruned downstream interfaces but has not sent a prune 835 upstream, then the receiving interface can simply be added to the 836 list of downstream interfaces in the forwarding cache. A Graft 837 Acknowledgment must also be sent back to the source of the Graft 838 message. If the receiving router has no state at all for the 839 (source, group) pair, then datagrams arriving for the (source, group) 840 pair should automatically be flooded when they arrive. A Graft 841 Acknowledgment must be sent to the source of the Graft message. If a 842 Graft message is received from an unknown neighbor, it should be 843 discarded. 845 3.6.4. Graft Packet Format 847 The format of a Graft packet is show below: 849 7 15 23 31 850 +-------------+--------------+-----------------------------+ 851 | Type | Code | Checksum | 852 | (0x13) | (0x8) | | 853 +-------------+--------------+--------------+--------------+ 854 | Reserved | Capabilities | Minor | Major | 855 +-------------+--------------+--------------+--------------+ 856 | Source Address | 857 +----------------------------------------------------------+ 858 | Group Address | 859 +----------------------------------------------------------+ 861 Figure 6 - Graft Packet Format 863 3.6.5. Sending a Graft Acknowledgment 865 A Graft Acknowledgment packet is sent to a downstream neighbor in 866 response to receiving a Graft message. Grafts received from unknown 867 neighbors should be discarded but all other correctly formatted Graft 868 messages should be acknowledged. This is true even if no other action 869 is taken in response to receiving the Graft to prevent the source 870 from continually re-transmitting the Graft message. The Graft 871 Acknowledgment packet is identical to the Graft packet except that 872 the DVMRP code in the common header is set to Graft Ack. This allows 873 the receiver of the Graft Ack message to correctly identify which 874 Graft was acknowledged and stop the appropriate retransmission timer. 876 3.6.6. Receiving a Graft Acknowledgment 878 When a Graft Acknowledgment is received, the (source, group) pair in 879 the packet can be used to determine if a Graft was sent to this 880 particular upstream router. If no Graft was sent, the Graft Ack can 881 simply be ignored. If a Graft was sent, and the acknowledgment has 882 come from the correct upstream router, then it has been successfully 883 received and the retransmission timer for the Graft can be stopped. 885 3.6.7. Graft Acknowledgment Packet Format 887 The format of a Graft Ack packet (which is identical to that of a 888 Graft packet is show below: 890 7 15 23 31 891 +-------------+--------------+-----------------------------+ 892 | Type | Code | Checksum | 893 | (0x13) | (0x9) | | 894 +-------------+--------------+--------------+--------------+ 895 | Reserved | Capabilities | Minor | Major | 896 +-------------+--------------+--------------+--------------+ 897 | Source Address | 898 +----------------------------------------------------------+ 899 | Group Address | 900 +----------------------------------------------------------+ 902 Figure 7 - Graft Ack Packet Format 904 3.7. Interfaces 906 Interfaces running DVMRP will either be multicast capable physical 907 interfaces or encapsulated tunnel pseudo-interfaces. Physical 908 interfaces may either be multi-access networks or point-to-point 909 networks. Tunnel interfaces are used when there are non-multicast 910 capable routers between DVMRP neighbors. Multicast data traffic is 911 sent between tunnel endpoints using IP-IP encapsulation. The unicast 912 IP addresses of the tunnel endpoints are used as the source and 913 destination IP addresses in the outer IP header. The inner IP header 914 remains unchanged from the original data packet. 916 Since DVMRP Protocol messages are not encapsulated when sent between 917 tunnel endpoints, they must always be sent directly to the unicast 918 address of the tunneled neighbor. 920 4. Security Considerations 922 Security for DVMRP follows the general security architecture provided 923 for the Internet Protocol [Atk95a]. This framework provides for both 924 privacy and authentication. It recommends the use of the IP 925 Authentication Header [Atk95b] to provide trusted neighbor 926 relationships. Confidentiality is provided by the addition of the IP 927 Encapsulating Security Payload [Atk95c]. Please refer to these 928 documents for the general architecture design as well as the specific 929 implementation details. 931 5. References 933 [Atk95a] Atkinson, R., "Security Architecture for the Internet 934 Protocol", RFC 1825, August 1995. 936 [Atk95b] Atkinson, R., "IP Authentication Header", RFC 1826, August 937 1995. 939 [Atk95c] Atkinson, R., "IP Encapsulating Security Payload (ESP)", 940 RFC 1827, August 1995. 942 [Deer89] Deering, S., "Host Extensions for IP Multicasting", RFC 943 1112, August 1989. 945 [Deer90] Deering, S., Cheriton, D., "Multicast Routing in Datagram 946 Internetworks and Extended LANs", ACM Transactions on 947 Computer Systems, Vol. 8, No. 2, May 1990, Pages 85-110. 949 [Fenn96] Fenner, W., "Internet Group Management Protocol, Version 950 2", Work In Progress, February 1996. 952 [Full93] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 953 Inter-Domain Routing (CIDR): an Address Assignment and 954 Aggregation Strategy", RFC 1519, September 1993. 956 [Perk96] Perkins, C., IP Encapsulation within IP, Work in Progress, 957 May 1996. 959 [Rekh93] Rekhter, Y., and T. Li, "An Architecture for IP Address 960 Allocation with CIDR", RFC 1518, September 1993. 962 [Wait88] Waitzman, D., Partridge, C., Deering, S., "Distance Vector 963 Multicast Routing Protocol", RFC 1075, November 1988. 965 6. Author's Address 967 Thomas Pusateri 968 Juniper Networks, Inc. 969 3260 Jay St. 970 Santa Clara, CA 95051 972 Phone: (919) 558-0700 973 EMail: pusateri@jnx.com 975 7. Acknowledgments 977 The author would like to acknowledge the original designers of the 978 protocol, Steve Deering, Craig Partridge, and David Waitzman. 979 Version 3 of the protocol would not have been possible without the 980 work of Ajit Thyagarajan and Bill Fenner. Credit also goes to Dave 981 LeRoy and Danny Mitzel for the careful review of this document. 983 8. Appendix A - Constants & Configurable Parameters 985 The following table provides a summary of the DVMRP timing 986 parameters: 988 Parameter Value (seconds) 989 ------------------------------------------------- 990 Probe Interval 10 991 Neighbor Time-out Interval 140 992 Route Report Interval 60 993 Route Replacement Time 140 994 Route Expiration Time 200 995 Prune Lifetime variable (< 300) 996 Graft Retransmission Time 5 with exp. backoff 997 ------------------------------------------------- 999 Table 2 - Parameter Summary 1001 9. Appendix B - Tracing and Troubleshooting support 1003 There are several packet types used to gather DVMRP specific 1004 information. They are generally used for diagnosing problems or 1005 gathering topology information. The first two messages are now 1006 obsoleted and should not be used. The remaining two messages provide 1007 a request/response mechanism to determine the versions and 1008 capabilities of a particular DVMRP router. 1010 Code Packet Type Description 1011 ----------------------------------------------------------- 1012 3 DVMRP Ask Neighbors Obsolete 1013 4 DVMRP Neighbors Obsolete 1014 5 DVMRP Ask Neighbors 2 Request Neighbor List 1015 6 DVMRP Neighbors 2 Respond with Neighbor List 1016 ----------------------------------------------------------- 1018 Table 3 - Debugging Packet Types 1020 9.1. DVMRP Ask Neighbors2 1022 The Ask Neighbors2 packet is a unicast request packet directed at a 1023 DVMRP router. The destination should respond with a unicast 1024 Neighbors2 message back to the sender of the Ask Neighbors2 message. 1026 0 8 16 31 1027 +---------+---------+--------------------+ 1028 | Type | Code | Checksum | 1029 |(0x13) | (0x5) | | 1030 +---------+---------+----------+---------+ 1031 | Reserved | Minor | Major | 1032 | | Version |Version | 1033 +-------------------+----------+---------+ 1035 Figure 8 - Ask Neighbors 2 Packet Format 1037 9.2. DVMRP Neighbors2 1039 The format of a Neighbors2 response packet is shown below. This is 1040 sent as a unicast message back to the sender of an Ask Neighbors2 1041 message. There is a common header at the top followed by the routers 1042 capabilities. One or more sections follow that contain an entry for 1043 each logical interface. The interface parameters are listed along 1044 with a variable list of neighbors learned on each interface. 1046 0 8 16 31 1047 +-----------+--------------+--------------------------+ 1048 | Type | Code | Checksum | 1049 | (0x13) | (0x6) | | 1050 +-----------+--------------+------------+-------------+ 1051 | Reserved | Capabilities | Minor | Major | 1052 | | | Version | Version | 1053 +-----------+--------------+------------+-------------+ 1054 | | 1055 | Local Addr 1 | 1056 +-----------+--------------+------------+-------------+ 1057 | | | | | 1058 | Metric 1 | Threshold 1 | Flags 1 | Nbr Count 1 | 1059 +-----------+--------------+------------+-------------+ 1060 | | 1061 | Nbr 1 | 1062 +-----------------------------------------------------+ 1063 | | 1064 | ... | 1065 +-----------------------------------------------------+ 1066 | | 1067 | Nbr m | 1068 +-----------------------------------------------------+ 1069 | | 1070 | Local Addr N | 1071 +-----------+--------------+------------+-------------+ 1072 | | | | | 1073 | Metric N | Threshold N | Flags N | Nbr Count N | 1074 +-----------+--------------+------------+-------------+ 1075 | | 1076 | Nbr 1 | 1077 +-----------------------------------------------------+ 1078 | | 1079 | ... | 1080 +-----------------------------------------------------+ 1081 | | 1082 | Nbr k | 1083 +-----------------------------------------------------+ 1085 Figure 9 - Neighbors 2 Packet Format 1087 The capabilities of the local router are defined as follows: 1089 Bit Flag Description 1090 --------------------------------------------------- 1092 0 Leaf This is a leaf router 1094 1 Prune This router understands pruning 1096 2 GenID This router sends Generation IDs 1098 3 Mtrace This router handles Mtrace requests 1099 --------------------------------------------------- 1101 Table 4 - DVMRP Router Capabilities 1103 The flags associated with a particular interface are: 1105 Bit Flag Description 1106 ---------------------------------------------------------- 1108 0 Tunnel Neighbor reached via tunnel 1110 1 Source Route Tunnel uses IP source routing 1112 2 Reserved No longer used 1114 3 Down Operational status down 1116 4 Disabled Administrative status down 1118 5 Reserved No longer used 1120 6 Leaf No downstream neighbors on interface 1121 ---------------------------------------------------------- 1123 Table 5 - DVMRP Interface flags 1125 10. Appendix C - Version Compatibility 1127 There have been two previous major versions of DVMRP with 1128 implementations still in circulation. If the receipt of a Probe 1129 message reveals a major version of 1 or 2, then it can be assumed 1130 that this neighbor does not support pruning or the use of the 1131 Generation ID in the Probe message. However, since these older 1132 implementations are known to safely ignore the Generation ID and 1133 neighbor information in the Probe packet, it is not necessary to 1134 send specially formatted Probe packets to these neighbors. 1136 There were two minor versions (1 and 2) of major version 3 that 1137 did support pruning but did not support the Generation ID or 1138 capability flags. These special cases will have to be accounted 1139 for. 1141 Any other minor versions of major version 3 conform to this 1142 specification. 1144 In addition, cisco Systems is known to use their software major 1145 and minor release number as the DVMRP major and minor version 1146 number. These will typically be 10 or 11 for the major version 1147 number. These implementations do support pruning but do not 1148 support the Generation ID in the Probe message. 1150 Table of Contents 1152 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 1153 1.1. Reverse Path Multicasting . . . . . . . . . . . . . . 2 1154 1.2. IP-IP Tunnels . . . . . . . . . . . . . . . . . . . . 2 1155 1.3. Document Overview . . . . . . . . . . . . . . . . . . 2 1156 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 3 1157 2.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . 3 1158 2.2. Source Location . . . . . . . . . . . . . . . . . . . 3 1159 2.3. Dependent Downstream Routers . . . . . . . . . . . . . 4 1160 2.4. Building Multicast Trees . . . . . . . . . . . . . . . 5 1161 2.5. Pruning Multicast Trees . . . . . . . . . . . . . . . 6 1162 2.6. Grafting Multicast Trees . . . . . . . . . . . . . . . 7 1163 3. Detailed Protocol Operation . . . . . . . . . . . . . . . . 7 1164 3.1. Protocol Header . . . . . . . . . . . . . . . . . . . 8 1165 3.2. Probe Messages . . . . . . . . . . . . . . . . . . . . 9 1166 3.3. Building Forwarding Cache Entries . . . . . . . . . . 12 1167 3.4. Unicast Route Exchange . . . . . . . . . . . . . . . . 13 1168 3.5. Pruning . . . . . . . . . . . . . . . . . . . . . . . 17 1169 3.6. Grafting . . . . . . . . . . . . . . . . . . . . . . . 20 1170 3.7. Interfaces . . . . . . . . . . . . . . . . . . . . . . 23 1171 4. Security Considerations . . . . . . . . . . . . . . . . . . 23 1172 5. References . . . . . . . . . . . . . . . . . . . . . . . . 25 1173 6. Author's Address . . . . . . . . . . . . . . . . . . . . . 25 1174 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26 1175 8. Appendix A - Constants & Configurable Parameters . . . . . 27 1176 9. Appendix B - Tracing and Troubleshooting support . . . . . 28 1177 9.1. DVMRP Ask Neighbors2 . . . . . . . . . . . . . . . . . 28 1178 9.2. DVMRP Neighbors2 . . . . . . . . . . . . . . . . . . . 29 1179 10. Appendix C - Version Compatibility . . . . . . . . . . . . 33