idnits 2.17.1 draft-ietf-idmr-dvmrp-v3-05.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-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Deer90], [Wait88]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 389: '...igured for DVMRP SHOULD have an interv...' RFC 2119 keyword, line 390: '... time-out interval SHOULD be set at 35...' RFC 2119 keyword, line 392: '...y multicast routers. These values MUST...' RFC 2119 keyword, line 417: '... the future and MUST be set to 0. Bit...' RFC 2119 keyword, line 418: '...earch topic. It MUST be set to 0. Bi...' (18 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 318 has weird spacing: '...ets are encap...' == Line 350 has weird spacing: '...aft Ack for ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: All of the active routes MUST be advertised over all interfaces with neighbors present each Route Report Interval. In addition, flash updates MAY be sent as needed but any given route MUST not be advertised more often than the Minimum Flash Update Interval (5 seconds). Flash updates can reduce the chances of routing loops and black holes occurring when source networks become unreachable through a particular path. Flash updates need only contain the source networks that have changed. It is not necessary to report all of the source networks from a particular mask value when sending an update. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1997) is 9662 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: '00' on line 681 ** 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. 'Deer91' -- Possible downref: Non-RFC (?) normative reference: ref. 'Fenn96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Fenn97' ** Obsolete normative reference: RFC 1519 (ref. 'Full93') (Obsoleted by RFC 4632) -- Possible downref: Non-RFC (?) normative reference: ref. 'Perl92' ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. 'Rekh93') -- Possible downref: Non-RFC (?) normative reference: ref. 'Reyn94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Thal97' ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. 'Wait88') Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 T. Pusateri 3 INTERNET DRAFT Juniper Networks 4 Obsoletes: RFC 1075 October 1997 5 draft-ietf-idmr-dvmrp-v3-05 Expires: April 1998 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 connection-less datagram delivery to a group of hosts 31 across an internetwork. It is a distributed protocol that dynamically 32 generates IP Multicast delivery trees using a technique called 33 Reverse Path Multicasting (RPM) [Deer90]. This document is an update 34 to Version 1 of the protocol specified in RFC 1075 [Wait88]. 36 1. Introduction 38 DVMRP uses a distance vector distributed routing algorithm in order 39 for each router to determine the distance from itself to any IP 40 Multicast traffic source. By determining the best path back to a 41 source, a router can know which interface it should expect traffic 42 from that source to arrive on. A good introduction to distance 43 vector routing can be found in [Perl92]. The application of distance 44 vector routing to multicast tree formulation is described in 45 [Deer91]. 47 1.1. Reverse Path Multicasting 49 Datagrams follow multicast delivery trees from a source to all 50 members of a multicast group [Deer89], replicating the packet only at 51 necessary branches in the delivery tree. The trees are calculated and 52 updated dynamically to track the membership of individual groups. 53 When a datagram arrives on an interface, the reverse path to the 54 source of the datagram is determined by examining a DVMRP routing 55 table of known source networks. If the datagram arrives on an 56 interface that would be used to transmit datagrams back to the 57 source, then it is forwarded to the appropriate list of downstream 58 interfaces. Otherwise, it is not on the optimal delivery tree and 59 should be discarded. In this way duplicate packets can be filtered 60 when loops exist in the network topology. The source specific 61 delivery trees are automatically pruned back as group membership 62 changes or leaf routers determine that no group members are present. 63 This keeps the delivery trees to the minimum branches necessary to 64 reach all of the group members. New sections of the tree can also be 65 added dynamically as new members join the multicast group by grafting 66 the new sections onto the delivery trees. 68 1.2. IP-IP Tunnels 70 Because not all IP routers support native multicast routing, DVMRP 71 includes direct support for tunneling IP Multicast datagrams through 72 routers. The IP Multicast datagrams are encapsulated in unicast IP 73 packets and addressed to the routers that do support native multicast 74 routing. DVMRP treats tunnel interfaces in an identical manner to 75 physical network interfaces. 77 In previous implementations, DVMRP protocol messages were sent un- 78 encapsulated to the unicast tunnel endpoint address. While this was 79 more direct, it increased the complexity of firewall configuration. 80 Therefore, all DVMRP protocol messages sent to tunnel endpoint 81 addresses should now be encapsulated in IP protocol 4 packets just as 82 multicast data packets are encapsulated. See Appendix C for backward 83 compatibility issues. More information on encapsulated tunnels can 84 be found in [Perk96]. 86 1.3. Document Overview 88 Section 2 provides an overview of the protocol and the different 89 message types exchanged by DVMRP routers. Those who wish to gain a 90 general understanding of the protocol but are not interested in the 91 more precise details may wish to only read this section. Section 3 92 explains the detailed operation of the protocol to accommodate 93 developers needing to provide inter-operable implementations. 94 Included in Appendix A, is a summary of the DVMRP parameters. A 95 section on DVMRP support for tracing and troubleshooting is the topic 96 of Appendix B. Finally, a short DVMRP version compatibility section 97 is provided in Appendix C to assist with backward compatibility 98 issues. 100 2. Protocol Overview 102 DVMRP can be summarized as a "broadcast & prune" multicast routing 103 protocol. It performs Reverse Path Forwarding checks to determine 104 when multicast traffic should be forwarded to downstream interfaces. 105 In this way, source-rooted shortest path trees can be formed to reach 106 all group members from each source network of multicast traffic. 108 2.1. Neighbor Discovery 110 Neighbor DVMRP routers can be discovered dynamically by sending 111 Neighbor Probe Messages on local multicast capable network interfaces 112 and tunnel pseudo interfaces. These messages are sent periodically to 113 the All-DVMRP-Routers IP Multicast group address. This address falls 114 into the range of IP Multicast addresses that are to remain on the 115 locally attached IP network and therefore are not forwarded by 116 multicast routers. 118 Each Neighbor Probe message should contain the list of Neighbor DVMRP 119 routers for which Neighbor Probe messages have been received on that 120 interface. In this way, Neighbor DVMRP routers can ensure that they 121 are seen by each other. Care must be taken to inter-operate with 122 older implementations of DVMRP that do not include this list of 123 neighbors. It can be assumed that older implementations of DVMRP 124 will safely ignore this list of neighbors in the Probe message. 125 Therefore, it is not necessary to send both old and new types of 126 Neighbor Probes. 128 2.2. Source Location 130 When an IP Multicast datagram is received by a router running DVMRP, 131 it first looks up the source network in the DVMRP routing table. The 132 interface of the next hop of packets sent back to the source of the 133 datagram is called the upstream interface. If the datagram arrived 134 on the correct upstream interface, then it is a candidate for 135 forwarding to one or more downstream interfaces. If the datagram did 136 not arrive on the anticipated upstream interface, it is discarded. 137 This check is known as a reverse path forwarding check and must be 138 performed by all DVMRP routers. 140 In order to ensure that all DVMRP routers have a consistent view of 141 the path back to a source, a routing table is propagated to all DVMRP 142 routers as an integral part of the protocol. Each router advertises 143 the network number and mask of the interfaces it is directly 144 connected to as well as relaying the routes received from neighbor 145 routers. DVMRP requires an interface metric to be configured on all 146 physical and tunnel interfaces. When a route is received, the metric 147 of the upstream interface over which the datagram was received must 148 be added to the metric of the route being propagated. This adjusted 149 metric should be computed before the route is compared to the metric 150 of the current next hop gateway. 152 Although there is certainly additional overhead associated with 153 propagating a separate DVMRP routing table, it does provide two nice 154 features. First, since all DVMRP routers are exchanging the same 155 routes, there are no inconsistencies between routers when determining 156 the upstream interface (aside from normal convergence issues related 157 to distance vector routing protocols). By placing the burden of 158 synchronization on the protocol as opposed to the network manager, 159 DVMRP reduces the risk of creating routing loops or black holes due 160 to disagreement between neighbor routers on the upstream interface. 162 Second, by propagating its own routing table, DVMRP makes it 163 convenient to have separate paths for unicast vs. multicast 164 datagrams. Although, ideally, many network managers would prefer to 165 keep their unicast and multicast traffic aligned, tunneled multicast 166 topologies may prevent this causing the unicast and multicast paths 167 to diverge. Additionally, service providers may prefer to keep the 168 unicast and multicast traffic separate for routing policy reasons as 169 they experiment with IP multicast routing and begin to offer it as a 170 service. 172 2.3. Dependent Downstream Routers 174 In addition to providing a consistent view of source networks, the 175 exchange of routes in DVMRP provides one other important feature. 176 DVMRP uses the route exchange as a mechanism for upstream routers to 177 determine if any downstream routers depend on them for forwarding 178 from particular source networks. DVMRP accomplishes this by using a 179 technique called "Poison Reverse". If a downstream router selects an 180 upstream router as the best next hop to a particular source network, 181 this is indicated by echoing back the route to the upstream router 182 with a metric equal to the original metric plus infinity. When the 183 upstream router receives the report and sees a metric that lies 184 between infinity and twice infinity, it can then add the downstream 185 router from which it received the report to a list of dependent 186 routers for this source. 188 This list of dependent routers per source network built by the 189 "Poison Reverse" technique will provide the foundation necessary to 190 determine when it is appropriate to prune back the IP source specific 191 multicast trees. 193 2.4. Designated Forwarder 195 When two or more DVMRP routers are connected to a multi-access 196 network, it is possible for duplicate packets to be forwarded on the 197 network (one copy from each router). DVMRP does not require a special 198 mechanism to prevent duplication. Instead, this feature is a 199 consequence of the route exchange. When two routers on a multi-access 200 network exchange source networks, each of the routers will know the 201 others metric back to each source network. Therefore, of all the 202 DVMRP routers on a shared network, the router with the lowest metric 203 to a source network is responsible for forwarding data on to the 204 shared network. If two or more routers have an equally low metric, 205 the router with the lowest IP address becomes the designated 206 forwarder for the network. In this way, DVMRP does an implicit 207 designated forwarder election for each source network on each 208 downstream interface. 210 2.5. Building Multicast Trees 212 As previously mentioned, when an IP multicast datagram arrives, the 213 upstream interface is determined by looking up the interface that 214 would be used if a datagram was being sent back to the source of the 215 datagram. If the upstream interface is correct, then a DVMRP router 216 will forward the datagram to a list of downstream interfaces. 218 2.5.1. Adding Leaf Networks 220 Initially, the DVMRP router must consider all of the remaining IP 221 multicast capable interfaces (including tunnels) on the router. If 222 the downstream interface under consideration is a leaf network (has 223 no dependent downstream neighbors for the source network), then the 224 IGMP local group database must be consulted. DVMRP routers can easily 225 determine if a directly attached network is a leaf network by keeping 226 a list of all routers from which DVMRP Router Probe messages have 227 been received on the interface. Obviously, it is necessary to refresh 228 this list and age out entries received from routers that are no 229 longer being refreshed. The IGMP local group database is maintained 230 by all IP multicast routers on each physical, multicast capable 231 network. The details of the election procedure are discussed in 232 [Fenn97]. If the destination group address is listed in the local 233 group database, and the router is the designated forwarder for the 234 source, then the interface should be included in the list of 235 downstream interfaces. If there are no group members on the 236 interface, then the interface can be removed from the outgoing 237 interface list. 239 2.5.2. Adding Non-Leaf Networks 241 Initially, all non-leaf networks should be included in the downstream 242 interface list when a forwarding cache entry is first being created. 243 This allows all downstream routers to be aware of traffic destined 244 for a particular (source network, group) pair. The downstream routers 245 will then have the option to send prunes and grafts for this (source 246 network, group) pair as requirements change from their respective 247 downstream routers and local group members. 249 2.6. Pruning Multicast Trees 251 As mentioned above, routers at the edges with leaf networks will 252 remove their leaf interfaces that have no group members associated 253 with an IP multicast datagram. If a router removes all of its 254 downstream interfaces, it can notify the upstream router that it no 255 longer wants traffic destined for a particular (source network, 256 group) pair. This is accomplished by sending a DVMRP Prune message 257 upstream to the router it expects to forward datagrams from a 258 particular source. 260 Recall that a downstream router will inform an upstream router that 261 it depends on the upstream router to receive datagrams from 262 particular source networks by using the "Poison Reverse" technique 263 during the exchange of DVMRP routes. This method allows the upstream 264 router to build a list of downstream routers on each interface that 265 are dependent upon it for datagrams from a particular source network. 266 If the upstream router receives prune messages from each one of the 267 dependent downstream routers on an interface, then the upstream 268 router can in turn remove this interface from its downstream 269 interface list. If the upstream router is able to remove all of its 270 downstream interfaces in this way, it can then send a DVMRP Prune 271 message to its upstream router. This continues until the unneeded 272 branches are removed from the delivery tree. 274 In order to remove old prune state information for (source network, 275 group) pairs that are no longer active, it is necessary to limit the 276 life of a prune and periodically resume the flooding procedure. 277 Inside the prune message is a prune lifetime. This indicates the 278 length of time that the prune should remain in effect. When the prune 279 lifetime expires, the interface is joined back onto the multicast 280 delivery tree. If unwanted multicast datagrams continue to arrive, 281 the prune mechanism will be re-initiated and the cycle will continue. 282 If all of the downstream interfaces are removed from a multicast 283 delivery tree causing a DVMRP Prune message to be sent upstream, the 284 lifetime of the prune sent will be equal to the minimum of the 285 remaining prune lifetimes of the downstream interfaces. 287 2.7. Grafting Multicast Trees 289 Once a tree branch has been pruned from a multicast delivery tree, 290 packets from the corresponding (source network, group) pair will no 291 longer be forwarded. However, since IP multicast supports dynamic 292 group membership, new hosts may join the multicast group. In this 293 case, DVMRP routers use Grafts to undo the prunes that are in place 294 from the host back on to the multicast delivery tree. A router will 295 send a Graft message to its upstream neighbor if a group join occurs 296 for a group that the router has previously sent a prune. Separate 297 Graft messages must be sent to the appropriate upstream neighbor for 298 each source network that has been pruned. Since there would be no 299 way to tell if a Graft message sent upstream was lost or the source 300 simply quit sending traffic, it is necessary to acknowledge each 301 Graft message with a DVMRP Graft Ack message. If an acknowledgment 302 is not received within a Graft Time-out period, the Graft message 303 should be retransmitted. Duplicate Graft Ack messages should simply 304 be ignored. The purpose of the Graft Ack message is to simply 305 acknowledge the receipt of a Graft message. It does not imply that 306 any action was taken as a result of receiving the Graft message. 307 Therefore, all Graft messages should be acknowledged whether or not 308 they cause an action on the receiving router. 310 3. Detailed Protocol Operation 312 This section contains a detailed description of DVMRP. It covers 313 sending and receiving of DVMRP messages as well as the generation and 314 maintenance of IP Multicast forwarding cache entries. 316 3.1. Protocol Header 318 DVMRP packets are encapsulated in IP datagrams, with an IP protocol 319 number of 2 (IGMP) as specified in the Assigned Numbers RFC [Reyn94]. 320 All fields are transmitted in Network Byte Order. DVMRP packets use a 321 common protocol header that specifies the IGMP [Fenn97] Packet Type 322 as hexadecimal 0x13 (DVMRP). DVMRP protocol packets should be sent 323 with the Precedence field in the IP header set to Internetwork 324 Control. A diagram of the common protocol header follows: 326 0 8 16 31 327 +---------+---------+--------------------+ 328 | Type | Code | Checksum | 329 |(0x13) | | | 330 +---------+---------+----------+---------+ 331 | Reserved | Minor | Major | 332 | | Version |Version | 333 +-------------------+----------+---------+ 335 Figure 1 - Common Protocol Header 337 A Major Version of 3 and a Minor Version of 0xFF should be used to 338 indicate compliance with this specification. The value of the Code 339 field determines the DVMRP packet type. Currently, there are codes 340 allocated for DVMRP protocol message types as well as protocol 341 analysis and troubleshooting packets. The protocol message Codes 342 are: 344 Code Packet Type Description 345 ---------------------------------------------------------------- 346 1 DVMRP Probe for neighbor discovery 347 2 DVMRP Report for route exchange 348 7 DVMRP Prune for pruning multicast delivery trees 349 8 DVMRP Graft for grafting multicast delivery trees 350 9 DVMRP Graft Ack for acknowledging graft messages 351 ---------------------------------------------------------------- 353 Table 1 - Standard Protocol Packet Types 355 There are additional codes used for protocol analysis and 356 troubleshooting. These codes are discussed in Appendix B. The 357 Checksum is the 16-bit one's complement of the one's complement sum 358 of the DVMRP message. The checksum of the DVMRP message should be 359 calculated with the checksum field set to zero. 361 3.2. Probe Messages 363 When a DVMRP router is configured to run on an interface (physical or 364 tunnel), it sends local IP Multicast discovery packets to inform 365 other DVMRP routers that it is operational. These discovery packets 366 are called DVMRP Probes and they serve three purposes. 368 1. Probes provide a mechanism for DVMRP routers to locate each other. 369 DVMRP sends a list of detected neighbors on each interface in the 370 Probe message. This list of DVMRP neighbors provides a foundation 371 for the dependent downstream neighbor list. If no DVMRP neighbors 372 are found, the network is considered to be a leaf network. A DVMRP 373 router should discard all other protocol packets from a neighbor 374 until it has seen its own address in the neighbors Probe list. 375 (See Appendix C for exceptions.) 377 2. Probes provide a way for DVMRP routers to determine the 378 capabilities of each other. This may be deduced from the major and 379 minor version numbers in the Probe packet or directly from the 380 capability flags. These flags were first introduced to allow 381 optional protocol features. This specification now mandates the 382 use of Generation Id's and pruning and, therefore, provides no 383 optional capabilities. Other capability flags were used for 384 tracing and troubleshooting and are no longer a part of the actual 385 protocol. 387 3. Probes provide a keep-alive function in order to quickly detect 388 neighbor loss. DVMRP probes sent on each multicast capable 389 interface configured for DVMRP SHOULD have an interval of 10 390 seconds. The neighbor time-out interval SHOULD be set at 35 391 seconds. This allows fairly early detection of a lost neighbor yet 392 provides tolerance for busy multicast routers. These values MUST 393 be coordinated between all DVMRP routers on a physical network 394 segment. 396 3.2.1. Router Capabilities 398 In the past, there have been many versions of DVMRP in use with a 399 wide range of capabilities. Practical considerations require a 400 current implementation to inter-operate with these older 401 implementations that don't formally specify their capabilities and 402 are not compliant with this specification. For instance, for major 403 versions less than 3, it can be assumed that the neighbor does not 404 support pruning. The formal capability flags were first introduced 405 in an well known implementation (Mrouted version 3.5) in an attempt 406 to take the guess work out which features are supported by a 407 neighbor. Many of these flags are no longer necessary since they are 408 now a required part of the protocol, however, special consideration 409 is necessary to not confuse older implementations that expect these 410 flags to be set. Appendix C was written to assist with these and 411 other backward compatibility issues. 413 Three of the flags were used for actual protocol operation. The 414 other two assigned flags were used for troubleshooting purposes which 415 should be documented in a separate specification. All of the bits 416 marked "U" in the Figure below are now unused. They may be defined in 417 the future and MUST be set to 0. Bit position 0 is the LEAF bit which 418 is a current research topic. It MUST be set to 0. Bit positions 1, 419 2, and 3 MUST be set to 1 for backward compatibility. They were used 420 to specify the PRUNE, GENID, and MTRACE bits. The first two, PRUNE 421 and GENID, are now required features. The MTRACE bit must be set so 422 existing implementations will not assume this neighbor does not 423 support multicast trace-route [Fenn96]. However, since this bit is 424 now reserved and set to 1, newer implementations should not use this 425 bit in the Probe message to determine if multicast trace-route is 426 supported by a neighbor. Instead, the M bit should only be used in a 427 Neighbors2 message as described in Appendix B. The bit marked S 428 stands for SNMP capable. This bit is used by troubleshooting 429 applications and should only be tested in the Neighbors2 message. 431 7 6 5 4 3 2 1 0 432 S M G P L 433 +---+---+---+---+----+---+---+---+ 434 |0 |0 |0 | 0 | 1 |1 |1 | 0 | 435 +---+---+---+---+----+---+---+---+ 437 Figure 2 - Probe Capability Flags 439 3.2.2. Generation ID 441 If a DVMRP router is restarted, it will want to learn all of the 442 routes known by its neighbors without having to wait for an entire 443 report interval to pass. In order for the neighbor to detect that the 444 router has restarted, a non-decreasing number is placed in the 445 periodic probe message called the generation ID. When a router 446 detects an increase in the generation ID of a neighbor, it should 447 send its entire routing table to the router. 449 If a change in generation ID is detected, any prune information 450 received from the router is no longer valid and should be flushed. 451 If this prune state has caused prune information to be sent upstream, 452 a graft will need to be sent upstream just as though a new member has 453 joined below. Once data begins to be delivered downstream, if the 454 downstream router again decides to be pruned from the delivery tree, 455 a new prune can be sent upstream at that time. 457 A time of day clock provides a good source for a non-decreasing 32 458 bit integer. 460 3.2.3. Neighbor Addresses 462 As a DVMRP router sees Probe messages from its DVMRP neighbors, it 463 records the neighbor addresses on each interface and places them in 464 the Probe message sent on the particular interface. This allows the 465 neighbor router to know that its probes have been received by the 466 sending router. 468 In order to minimize one-way neighbor relationships, a router MUST 469 delay sending poison route reports to a neighbor until the neighbor 470 includes the routers address in its probe messages. On point-to-point 471 interfaces and tunnel pseudo-interfaces, this means that no packets 472 should be forwarded onto these interfaces until two-way neighbor 473 relationships have formed. 475 Implementations written before this specification will not wait 476 before sending reports nor will they ignore reports sent. Therefore, 477 reports from these implementations SHOULD be accepted whether or not 478 a probe with the routers address has been received. 480 3.2.4. Neighbor Time-Out 482 When a neighbor times out, the following steps should be taken: 484 1. All routes learned by this neighbor should be immediately placed 485 in holddown. Forwarding cache entries may need to be updated. 487 2. All downstream dependencies by this neighbor should be canceled. 488 This may trigger prunes to be sent. 490 3.2.5. Probe Packet Format 492 The Probe packet is variable in length depending on the number of 493 neighbor IP addresses included. The length of the IP packet can be 494 used to determine the number of neighbors in the Probe message. The 495 current Major Version is 3. To maintain compatibility with previous 496 versions, implementations of Version 3 must include pruning and 497 grafting of multicast trees. Non-pruning implementations SHOULD NOT 498 be implemented at this time. 500 7 15 23 31 501 +---------+--------------+--------------------+ 502 | Type | Code | Checksum | 503 | (0x13) | (0x1) | | 504 +---------+--------------+----------+---------+ 505 | | | | | 506 |Reserved | Capabilities | Minor | Major | 507 +---------+--------------+----------+---------+ 508 | | 509 | Generation ID | 510 +---------------------------------------------+ 511 | | 512 | Neighbor IP Address 1 | 513 +---------------------------------------------+ 514 | | 515 | Neighbor IP Address 2 | 516 +---------------------------------------------+ 517 | | 518 | ... | 519 +---------------------------------------------+ 520 | | 521 | Neighbor IP Address N | 522 +---------------------------------------------+ 524 Figure 3 - DVMRP Probe Packet Format 526 3.2.6. Designated Router Election 528 Since it is wasteful to have more than a single router sending IGMP 529 Host Membership Queries on a given physical network, a single router 530 on each physical network is elected as the Designated Querier. This 531 election used to be a part of DVMRP. However, this is now handled as 532 a part of the IGMP version 2 protocol. Therefore, DVMRP Version 3 533 requires the use of IGMP Version 2 or later specifying that the 534 Designated Querier election is performed as a part of IGMP. 536 Even though only one router will act as the designated querier, all 537 DVMRP routers must listen to IGMP Host Membership Reports and keep a 538 local group database. 540 3.3. Building Forwarding Cache Entries 542 In order to create optimal multicast delivery trees, DVMRP was 543 designed to keep separate forwarding cache entries for each (source 544 network, destination group) pair. Because the possible combinations 545 of these is quite large, forwarding cache entries are generated on 546 demand as data arrives at a multicast router. Since the IP forwarding 547 decision is made on a hop by hop basis (as with the unicast case), it 548 is imperative that each multicast router has a consistent view of the 549 reverse path back to the source network. 551 3.3.1. Designated Forwarder 553 Initially, a DVMRP router should assume it is the designated 554 forwarder for all source networks on all downstream interfaces. As it 555 receives route reports, it can determine if other routers on multi- 556 access networks have better routes back to a particular source 557 network. A route is considered better if the received metric is less 558 than the metric that it will advertise for the source network on the 559 received interface or if the metrics are the same but the IP address 560 of the neighbor is lower. 562 If this neighbor becomes unreachable or starts advertising a worse 563 metric, then the router should become the designated forwarder for 564 this source network again on the downstream interface until it hears 565 from a better candidate. 567 If the upstream RPF interface changes, then the router should become 568 the designated forwarder on the previous upstream interface (which is 569 now a potential downstream interface) until it hears from a better 570 candidate. 572 3.3.2. Determining the upstream interface 574 When a multicast packet arrives, a DVMRP router will use the DVMRP 575 routing table to determine which interface leads back to the source. 576 If the packet did not arrive on that interface, it should be 577 discarded without further processing. Each multicast forwarding entry 578 should cache the upstream interface for a particular source host or 579 source network after looking this up in the DVMRP routing table. 581 3.3.3. Determining the downstream interface list 583 The downstream interface list is built from the remaining list of 584 multicast capable interfaces. Any interfaces designated as leaf 585 networks that do not have members of the particular multicast group 586 can be automatically removed from list of downstream interfaces. The 587 remaining interfaces will either have downstream DVMRP routers or 588 directly attached group members. If the router is not the designated 589 forwarder on interfaces with directly attached group members, these 590 interfaces can be removed as well. This prevents duplicate packets 591 from arriving on multi-access networks. 593 3.4. Route Exchange 595 It was mentioned earlier that since not all IP routers support IP 596 multicast forwarding, it is necessary to tunnel IP multicast 597 datagrams through these routers. One effect of using these 598 encapsulated tunnels is that IP multicast traffic may not be aligned 599 with IP unicast traffic. This means that a multicast datagram from a 600 particular source can arrive on a different (logical) interface than 601 the expected upstream interface based on traditional unicast routing. 603 The routing information propagated by DVMRP is used for determining 604 the reverse path back to the source of multicast traffic. Tunnel 605 pseudo-interfaces are considered to be distinct for the purpose of 606 determining upstream and downstream interfaces. The routing 607 information that is propagated by DVMRP contains a list of source 608 networks and an appropriate metric. The metric used is a hop count 609 which is incremented by the cost of the incoming interface metric. 610 Traditionally, physical interfaces use a metric of 1 while the metric 611 of a tunnel interface varies with the distance and bandwidth in the 612 path between the two tunnel endpoints. Users are encouraged to 613 configure tunnels with the same metric in each direction to create 614 symmetric routing and provide for easier problem determination 615 although the protocol does not strictly enforce this. 617 3.4.1. Source Network Aggregation 619 Implementations may wish to provide a mechanism to aggregate source 620 networks to reduce the size of the routing table. All implementations 621 should be able to accept reports for aggregated source networks in 622 accordance with Classless Inter-Domain Routing (CIDR) as described in 623 [Rekh93] and [Full93]. 625 There are two places where aggregation is particularly useful. 627 1. At organizational boundaries to limit the number of source 628 networks advertised out of the organization. 630 2. Within an organization to summarize non-local routing information 631 by using a default (0/0) route. 633 If an implementation wishes to support source aggregation, it MUST 634 transmit Prune and Graft messages according to the following rules: 636 A. If a Prune is received on a downstream interface for which the 637 source network advertised to that neighbor is an aggregate 638 generated by the receiving router, then only a single Prune should 639 be sent upstream (if necessary) to the router advertising the best 640 matching source network component of the aggregate. 642 B. If a Graft is received on a downstream interface for which the 643 source network advertised to that neighbor is an aggregate 644 generated by the receiving router, then Graft messages MUST be 645 sent upstream (if necessary) to the neighbors advertising each of 646 the source networks that were used to generate the aggregate. 648 3.4.2. Route Packing and Ordering 650 Since DVMRP Route Reports may need to refresh several thousand routes 651 each report interval, routers MUST attempt to spread the routes 652 reported across the whole route update interval. This reduces the 653 chance of synchronized route reports causing routers to become 654 overwhelmed for a few seconds each report interval. Since the route 655 report interval is 60 seconds, it is suggested that the total number 656 routes being updated be split across multiple Route Reports sent at 657 regular intervals. There was an earlier requirement that Route 658 Reports MUST contain source network/mask pairs sorted first by 659 increasing network mask and then by increasing source network. This 660 restriction has been lifted. Implementations conforming to this 661 specification MUST be able to receive Route Reports containing any 662 mixture of network masks and source networks. 664 In order to pack more source networks into a route report, source 665 networks are often represented by less than 4 octets. The number of 666 non-zero bytes in the mask value is used to determine the number of 667 octets used to represent each source network within that particular 668 mask value. For instance if the mask value of 255.255.0.0 is being 669 reported, the source networks would only contain 2 octets each. DVMRP 670 assumes that source networks will never be aggregated into networks 671 whose prefix length is less than 8. Therefore, it does not carry the 672 first octet of the mask in the Route Report since, given this 673 assumption, the first octet will always be 0xFF. This means that the 674 netmask value will always be represented in 3 octets. This method of 675 specifying source network masks is compatible with techniques 676 described in [Rekh93] and [Full93] to group traditional Class C 677 networks into super-nets and to allow different subnets of the same 678 Class A network to be discontinuous. In this notation, the default 679 route is represented as the least three significant octets of the 680 netmask [00 00 00], followed by one octet for the network number 681 [00]. 683 3.4.3. Route Metrics 685 For each source network reported, a route metric is associated with 686 the route being reported. The metric is the sum of the interface 687 metrics between the router originating the report and the source 688 network. For the purposes of DVMRP, the Infinity metric is defined to 689 be 32. This limits the breadth across the whole DVMRP network and is 690 necessary to place an upper bound on the convergence time of the 691 protocol. 693 As seen in the packet format below, Route Reports do not contain a 694 count of the number of routes reported for each netmask. Instead, the 695 high order bit of the metric is used to signify the last route being 696 reported for a particular mask value. If a metric is read with the 697 high order bit of the 8-bit value set and if the end of the message 698 has not been reached, the next value will be a new netmask to be 699 applied to the subsequent list of routes. 701 3.4.4. Route Dependencies 703 In order for pruning to work correctly, each DVMRP router needs to 704 know which downstream routers depend on it for receiving datagrams 705 from particular source networks. Initially, when a new datagram 706 arrives from a particular source/group pair, it is flooded to all 707 downstream interfaces that have DVMRP neighbors who have indicated a 708 dependency on the receiving DVMRP router for that particular source. 709 A downstream interface can only be removed when it has received Prune 710 messages from each of the dependent routers on that interface. Each 711 downstream router uses Poison Reverse to indicate to the upstream 712 router which source networks it expects to receive from the upstream 713 router. The downstream router indicates this by echoing back the 714 source networks it expects to receive from the upstream router with 715 infinity added to the advertised metric. This means that the legal 716 values for the metric now become between 1 and (2 x Infinity - 1) or 717 1 and 63. Values between 1 and 31 indicate reachable source networks. 718 The value Infinity (32) indicates the source network is not 719 reachable. Values between 33 and 63 indicate that the downstream 720 router originating the Report is depending upon the upstream router 721 to provide multicast datagrams from the corresponding source network. 723 3.4.5. Sending Route Reports 725 All of the active routes MUST be advertised over all interfaces with 726 neighbors present each Route Report Interval. In addition, flash 727 updates MAY be sent as needed but any given route MUST not be 728 advertised more often than the Minimum Flash Update Interval (5 729 seconds). Flash updates can reduce the chances of routing loops and 730 black holes occurring when source networks become unreachable through 731 a particular path. Flash updates need only contain the source 732 networks that have changed. It is not necessary to report all of the 733 source networks from a particular mask value when sending an update. 735 When a router sees its own address in a neighbor probe packet for the 736 first time, it should send an entire copy of its routing table to the 737 neighbor to reduce start-up time. 739 Route Reports containing downstream dependent "poison" metrics MUST 740 be sent to the All-DVMRP-Routers address. These reports should not 741 be sent to a neighbor until a router has seen its own address in the 742 neighbors Probe router list. See Appendix C for exceptions. These 743 Reports should be refreshed at the standard Route Update Interval. 745 3.4.6. Receiving Route Reports 747 After receiving a route report, a check should be made to verify it 748 is from a known neighbor. Neighbors are learned via received Probe 749 messages which also indicate the capabilities of the neighbor. 750 Therefore, route reports from unknown neighbors are discarded. 752 Each route in the report is then parsed and processed according to 753 the following rules: 755 A. If the route is new and the metric is less than infinity, the 756 route should be added. 758 B. If the route already exists, several checks must be performed. 759 The new metric is defined as the metric received in the route 760 report plus the metric of the received interface. 762 1. New metric < infinity 764 If this neighbor is a downstream dependent neighbor, the 765 neighbor is now learning the route from another source. Cancel 766 the downstream dependency. 768 In the following cases, the designated forwarder for the source 769 network on the receiving interface may need to be updated. This 770 is true under the following conditions: 772 - If the new route is better and the router receiving the 773 report is currently the designated forwarder. 775 - If the new route is worse than the existing route and the 776 advertising router is currently the designated forwarder. 778 A route is considered better when either the received metric is 779 lower than the existing metric or the received metric is the 780 same but the advertising router's IP address is lower. 782 a. New metric > existing metric 784 If the new metric is greater than the existing metric then 785 check to see if the same neighbor is reporting the route. If 786 so, update the metric and flash update the route. 787 Otherwise, discard the route. 789 b. New metric < existing metric 791 Update the metric for the route and if the neighbor 792 reporting the route is different, update the upstream 793 neighbor in the routing table. Flash update the route to 794 downstream neighbors and if the upstream interface changed, 795 a flash poison update should be sent upstream indicating a 796 change in downstream dependency. 798 c. New metric = existing metric 800 If the neighbor reporting the route is the same as the 801 existing upstream neighbor, then simply refresh the route. 802 If the neighbor reporting the route has a lower IP address 803 than the existing upstream neighbor, then update the route. 804 If the upstream interface changes, a flash poison update 805 should be sent on the new interface. 807 Again, the receiving router may need to update its 808 designated forwarder status if the neighbor is a better 809 candidate. 811 2. Metric = infinity 812 If the neighbor was considered to be the designated 813 forwarder, the receiving router should now become the 814 designated forwarder for the source network on this 815 interface unless it knows of a better candidate. 817 a. Next hop = existing next hop 819 If the existing metric was less than infinity, the route is 820 now unreachable. Update the route and possibly flash update 821 the route as well. 823 b. Next hop != existing next hop 825 The route can be ignored since the existing next hop has a 826 metric better than or equal to this next hop. 828 If the neighbor was considered a downstream dependent 829 neighbor, this should be cancelled. Check to determine if 830 removing this neighbor triggers a Prune. 832 3. infinity < New metric < 2 x infinity 834 The neighbor considers the receiving router to be upstream for 835 the route and is indicating it is dependent on the receiving 836 router. 838 If the neighbor was considered to be the designated forwarder, 839 the receiving router should now become the designated forwarder 840 for the source network on this interface unless it knows of a 841 better candidate. 843 a. Neighbor on down stream interface 845 If the sending neighbor is considered to be on a downstream 846 interface for that route then the neighbor should be 847 registered as a downstream dependent router for that route. 849 If this is the first time the neighbor has indicated 850 downstream dependence for this source and one or more prunes 851 have been sent upstream containing this source network, then 852 Graft messages will need to be sent upstream in the 853 direction of the source network for each group with existing 854 prune state. 856 b. Neighbor not on down stream interface 858 If the receiving router thinks the neighbor is on the 859 upstream interface, then the indication of downstream 860 dependence should be ignored. 862 4. 2 x infinity <= New metric 864 If the metric is greater than or equal to 2 x infinity, the 865 metric is illegal and the route should be ignored. 867 3.4.7. Route Hold-down 869 When a route learned via a particular gateway expires, a router may 870 be able to reach the source network described by the route through an 871 alternate gateway. However, in the presence of complex topologies, 872 often, the alternate gateway may only be echoing back the same route 873 learned via a different path. If this occurs, the route will continue 874 to be propagated long after it is no longer valid. 876 In order to prevent this, it is common in distance vector protocols 877 to continue to advertise a route that has been deleted with a metric 878 of infinity for one or more report intervals. During this time, the 879 route may be learned via a different gateway and the router is 880 permitted to use this new gateway. However, the router MUST NOT 881 advertise this new gateway during the hold-down period. 883 DVMRP begins the hold-down period after 140 seconds (2 x Route Report 884 Interval + 20). After this time, a new gateway may be used but the 885 route must be advertised with an infinity metric for 2 Report 886 Intervals. At this point, the hold-down period is over and the new 887 gateway (if one exists) can start being advertised. In the absence 888 of a new gateway, the route is simply removed. 890 Route hold-down is not effective if only some of the routers 891 implement it. Therefore, it is now a REQUIRED part of the protocol. 893 In order to minimize outages caused by flapping routes, it is 894 permissible to prematurely take a route out of hold-down only if the 895 route is re-learned from the SAME router with the SAME metric. 897 3.4.8. Graceful Shutdown 899 During a graceful shutdown, an implementation MAY want to inform 900 neighbor routers that it is terminating. Routes that have been 901 advertised with a metric less than infinity should now be advertised 902 with a metric equal to infinity. This will allow neighbor routers to 903 switch more quickly to an alternate path for a source network if one 904 exists. 906 Routes that have been advertised with a metric between infinity and 2 907 x infinity (indicating downstream neighbor dependence) should now be 908 advertised with a metric equal to infinity (canceling the downstream 909 dependence). 911 3.4.9. Route Report Packet Format 913 The format of a sample Route Report Packet is shown in Figure 4 914 below. The packet shown is an example of how the source networks are 915 packed into a Report. The number of octets in each Source Network 916 will vary depending on the mask value. The values below are only an 917 example for clarity and are not intended to represent the format of 918 every Route Report. 920 7 15 23 31 921 +-----------+------------+-------------------------+ 922 | Type | Code | Checksum | 923 | (0x13) | (0x2) | | 924 +-----------+------------+------------+------------+ 925 | Reserved | Minor | Major | 926 | | Version | Version | 927 +-----------+------------+------------+------------+ 928 | Mask1 | Mask1 | Mask1 | Src | 929 | Octet2 | Octet3 | Octet4 | Net11 | 930 +-----------+------------+------------+------------+ 931 | SrcNet11(cont.)... | Metric11 | Src | 932 | | | Net12 | 933 +------------------------+------------+------------+ 934 | SrcNet12(cont.)... | Metric12 | Mask2 | 935 | | | Octet2 | 936 +-----------+------------+------------+------------+ 937 | Mask2 | Mask2 | SrcNet21 | 938 | Octet3 | Octet4 | | 939 +-----------+------------+------------+------------+ 940 | SrcNet21(cont.)... | Metric21 | Mask3 | 941 | | | Octet2 | 942 +-----------+------------+------------+------------+ 943 | Mask3 | Mask3 | ... | 944 | Octet3 | Octet4 | | 945 +-----------+------------+-------------------------+ 947 Figure 4 - Example Route Report Packet Format 949 3.5. Pruning 951 DVMRP is described as a broadcast and prune multicast routing 952 protocol since datagrams are initially sent out all dependent 953 downstream interfaces forming a tree rooted at the source of the 954 data. But as the routers at the leafs of the tree begin to receive 955 unwanted multicast traffic, they send prune messages upstream toward 956 the source. This allows the tree branches to become optimal for a 957 given source network and a given set of receivers. 959 3.5.1. Leaf Networks 961 Detection of leaf networks is very important to the pruning process. 962 Routers at the end of a source specific multicast delivery tree must 963 detect that there are no further downstream routers. This detection 964 mechanism is covered above in section 3.2 titled Probe Messages. If 965 there are no group members present for a particular multicast 966 datagram received, the leaf routers will start the pruning process by 967 removing their downstream interfaces and sending a prune to the 968 upstream router for that source. 970 3.5.2. Source Networks 972 It is important to note that prunes are specific to a group and 973 source network. A prune sent upstream triggered by traffic received 974 from a particular source applies to all sources on that network. It 975 is not currently possible to remove only one or a subset of hosts on 976 a source network for a particular group. All or none of the sources 977 must be removed. 979 Although the Prune message contains the host address of a source, the 980 source network can be determined easily by a best-match lookup using 981 the routing table distributed as a part of DVMRP. 983 3.5.3. Receiving a Prune 985 When a prune is received, the following steps should be taken: 987 1. If the neighbor is unknown, discard the received prune. 989 2. Since Prune messages are currently fixed length, ensure the prune 990 message contains at least the correct amount of data. 992 3. Extract the source address, group address, and prune time-out 993 values 995 4. If there is no current state information for the (source network, 996 group) pair, then ignore the prune. 998 5. Verify that the prune was received from a dependent neighbor for 999 the source network. If not, discard the prune. 1001 6. Determine if a prune is currently active from the same dependent 1002 neighbor for this (source network, group) pair. 1004 7. If so, reset the timer to the new time-out value. Otherwise, 1005 create state for the new prune and set a timer for the prune 1006 lifetime. 1008 8. Determine if all dependent downstream routers on the interface 1009 from which the prune was received have now sent prunes. 1011 9. If so, then determine if there are group members active on the 1012 interface. 1014 10. If no group members are found, then remove the interface. 1016 11. If all downstream interfaces have now been removed, send a prune 1017 to the upstream neighbor. 1019 3.5.4. Sending a Prune 1021 When sending a prune upstream, the following steps should be taken: 1023 1. Decide if upstream neighbor is capable of receiving prunes. 1025 2. If not, then proceed no further. 1027 3. Stop any pending Grafts awaiting acknowledgments. 1029 4. Determine the prune lifetime. This value should be the minimum of 1030 the prune lifetimes remaining from the downstream neighbors and 1031 the default prune lifetime. 1033 5. Form and transmit the packet to the upstream neighbor for the 1034 source. 1036 3.5.5. Retransmitting a Prune 1038 By increasing the prune lifetime to ~2 hours, the effect of a lost 1039 prune message becomes more apparent. Therefore, an implementation 1040 SHOULD choose to retransmit prunes messages using exponential back- 1041 off for the lifetime of the prune if traffic is still arriving on the 1042 upstream interface. 1044 One way to implement this would be to send a prune, install a 1045 negative cache entry for 3 seconds while waiting for the prune to 1046 take effect. Then remove the negative cache entry. If traffic 1047 continues to arrive, a new forwarding cache request will be 1048 generated. The prune can be resent with the remaining prune lifetime 1049 and a negative cache entry can be installed for 6 seconds. After 1050 this, the negative cache entry is removed. This procedure is repeated 1051 while each time doubling the length of time the negative cache entry 1052 is installed. 1054 The actual retransmission time should be randomized to reduce 1055 synchronized prune retransmissions. 1057 On multi-access networks, even if a prune is received correctly, data 1058 may still be received due to other receivers on the network. 1060 3.5.6. Prune Packet Format 1062 In addition to the standard IGMP and DVMRP headers, a Prune Packet 1063 contains three additional fields: the source host IP address, the 1064 destination group IP address, and the Prune Lifetime in seconds. 1066 The Prune Lifetime is a derived value calculated as the minimum of 1067 the default prune lifetime (2 hours) and the remaining lifetimes of 1068 of any downstream prunes received for the same cache entry. A router 1069 with no downstream dependent neighbors would use the the default 1070 prune lifetime. 1072 7 15 23 31 1073 +-----------+------------+-------------------------+ 1074 | Type | Code | Checksum | 1075 | (0x13) | (0x7) | | 1076 +-----------+------------+------------+------------+ 1077 | Reserved | Minor | Major | 1078 +------------------------+------------+------------+ 1079 | Source Address | 1080 +--------------------------------------------------+ 1081 | Group Address | 1082 +--------------------------------------------------+ 1083 | Prune Lifetime | 1084 +--------------------------------------------------+ 1086 Figure 5 - Prune Packet Format 1088 3.6. Grafting 1090 Once a multicast delivery tree has been pruned back, DVMRP Graft 1091 messages are necessary to join new receivers onto the multicast tree. 1092 Graft messages are sent upstream from the new receiver's first-hop 1093 router until a point on the multicast tree is reached. Graft 1094 messages are re-originated between adjacent DVMRP routers and are not 1095 forwarded by DVMRP routers. Therefore, the first-hop router does not 1096 know if the Graft message ever reaches the multicast tree. To remedy 1097 this, each Graft message is acknowledged hop by hop. This ensures 1098 that the Graft message is not lost somewhere along the path between 1099 the receiver's first-hop router and the closest point on the 1100 multicast delivery tree. 1102 One or more Graft messages should be sent under the following 1103 conditions: 1105 1. A new local member joins a group that has been pruned upstream. 1107 2. A new dependent downstream router appears on a pruned branch. 1109 3. A dependent downstream router on a pruned branch restarts (new 1110 Generation ID). 1112 4. A Graft Retransmission Timer expires before a Graft-Ack is 1113 received. 1115 3.6.1. Grafting Each Source Network 1117 It is important to realize that prunes are source specific and are 1118 sent up different trees for each source. Grafts are sent in response 1119 to a new Group Member which is not source specific. Therefore, 1120 separate Graft messages must be sent to the appropriate upstream 1121 routers to counteract each previous source specific prune that was 1122 sent. 1124 3.6.2. Sending a Graft 1126 As mentioned above, a Graft message sent to the upstream DVMRP router 1127 should be acknowledged hop by hop guaranteeing end-to-end delivery. 1128 If a Graft Acknowledgment is not received within the Graft 1129 Retransmission Time-out period, the Graft should be resent to the 1130 upstream router. The initial retransmission period is 5 seconds. A 1131 binary exponential back-off policy is used on subsequent 1132 retransmissions. In order to send a Graft message, the following 1133 steps should be taken: 1135 1. Verify a forwarding cache entry exists for the (source network, 1136 group) pair and that a prune exists for the cache entry. 1138 2. Verify that the upstream router is capable of receiving prunes 1139 (and therefore grafts). 1141 3. Add the graft to the retransmission timer list awaiting an 1142 acknowledgment. 1144 4. Formulate and transmit the Graft packet. 1146 3.6.3. Receiving a Graft 1148 The actions taken when a Graft is received depends on the state in 1149 the receiving router for the (source network, group) pair in the 1150 received Graft message. If the receiving router has prune state for 1151 the (source network, group) pair, then it must acknowledge the 1152 received graft and send a subsequent graft to its upstream router. 1153 If the receiving router has some removed some downstream interfaces 1154 but has not sent a prune upstream, then the receiving interface can 1155 simply be added to the list of downstream interfaces in the 1156 forwarding cache. A Graft Acknowledgment must also be sent back to 1157 the source of the Graft message. If the receiving router has no 1158 state at all for the (source network, group) pair, then datagrams 1159 arriving for the (source, group) pair should automatically be flooded 1160 when they arrive. A Graft Acknowledgment must be sent to the source 1161 of the Graft message. If a Graft message is received from an unknown 1162 neighbor, it should be discarded after it is acknowledged. 1164 3.6.4. Graft Packet Format 1166 The format of a Graft packet is show below: 1168 7 15 23 31 1169 +-----------+------------+-------------------------+ 1170 | Type | Code | Checksum | 1171 | (0x13) | (0x8) | | 1172 +-----------+------------+------------+------------+ 1173 | Reserved | Minor | Major | 1174 +------------------------+------------+------------+ 1175 | Source Address | 1176 +--------------------------------------------------+ 1177 | Group Address | 1178 +--------------------------------------------------+ 1180 Figure 6 - Graft Packet Format 1182 3.6.5. Sending a Graft Acknowledgment 1184 A Graft Acknowledgment packet is sent to a downstream neighbor in 1185 response to receiving a Graft message. All Graft messages should be 1186 acknowledged. This is true even if no other action is taken in 1187 response to receiving the Graft to prevent the source from 1188 continually re-transmitting the Graft message. The Graft 1189 Acknowledgment packet is identical to the Graft packet except that 1190 the DVMRP code in the common header is set to Graft Ack. This allows 1191 the receiver of the Graft Ack message to correctly identify which 1192 Graft was acknowledged and stop the appropriate retransmission timer. 1194 3.6.6. Receiving a Graft Acknowledgment 1196 When a Graft Acknowledgment is received, the (source address, group) 1197 pair in the packet can be used to determine if a Graft was sent to 1198 this particular upstream router. If no Graft was sent, the Graft Ack 1199 can simply be ignored. If a Graft was sent, and the acknowledgment 1200 has come from the correct upstream router, then it has been 1201 successfully received and the retransmission timer for the Graft can 1202 be stopped. 1204 3.6.7. Graft Acknowledgment Packet Format 1206 The format of a Graft Ack packet (which is identical to that of a 1207 Graft packet) is show below: 1209 7 15 23 31 1210 +-----------+------------+-------------------------+ 1211 | Type | Code | Checksum | 1212 | (0x13) | (0x9) | | 1213 +-----------+------------+------------+------------+ 1214 | Reserved | Minor | Major | 1215 +------------------------+------------+------------+ 1216 | Source Address | 1217 +--------------------------------------------------+ 1218 | Group Address | 1219 +--------------------------------------------------+ 1221 Figure 7 - Graft Ack Packet Format 1223 3.7. Interfaces 1225 Interfaces running DVMRP will either be multicast capable physical 1226 interfaces or encapsulated tunnel pseudo-interfaces. Physical 1227 interfaces may either be multi-access networks or point-to-point 1228 networks. Tunnel interfaces are used when there are non-multicast 1229 capable routers between DVMRP neighbors. Protocol messages and 1230 multicast data traffic are sent between tunnel endpoints using IP-IP 1231 encapsulation. The unicast IP addresses of the tunnel endpoints are 1232 used as the source and destination IP addresses in the outer IP 1233 header. The inner IP header remains unchanged from the original 1234 packet. 1236 When multiple addresses are configured on a single interface, it is 1237 necessary that all routers on the interface know about the same set 1238 of network addresses. In this way, each router will make the same 1239 choice for the designated forwarder for each source. In addition, a 1240 router configured with multiple addresses on an interface should 1241 consistently use the same address when sending DVMRP control 1242 messages. 1244 The maximum packet length of any DVMRP message should be the maximum 1245 packet size required to be forwarded without fragmenting. The use of 1246 Path MTU Discovery [Mogu90] is encouraged to determine this size. In 1247 the absence of Path MTU, the Requirements for Internet Hosts [Brad89] 1248 specifies this number as 576 octets. Be sure to consider the size of 1249 the encapsulated IP header as well when calculating the maximum size 1250 of a DVMRP protocol message. 1252 4. IANA Considerations 1254 The Internet Assigned Numbers Authority (IANA) is the central 1255 coordinator for the assignment of unique parameter values for 1256 Internet protocols. DVMRP uses IGMP [Fenn97] IP protocol messages to 1257 communicate between routers. The IGMP Type field is hexadecimal 0x13. 1259 On IP multicast capable networks, DVMRP uses the All-DVMRP-Routers 1260 local multicast group. This group address is 224.0.0.4. 1262 5. Network Management Considerations 1264 DVMRP provides several methods for network management monitoring and 1265 troubleshooting. Appendix B describes a request/response mechanism to 1266 directly query DVMRP neighbor information. In addition, a Management 1267 Information Base for DVMRP is defined in [Thal97]. A protocol 1268 independent multicast trace-route facility is defined in [Fenn96]. 1270 6. Security Considerations 1272 Security for DVMRP follows the general security architecture provided 1273 for the Internet Protocol [Atk95a]. This framework provides for both 1274 privacy and authentication. It recommends the use of the IP 1275 Authentication Header [Atk95b] to provide trusted neighbor 1276 relationships. Confidentiality is provided by the addition of the IP 1277 Encapsulating Security Payload [Atk95c]. Please refer to these 1278 documents for the general architecture design as well as the specific 1279 implementation details. 1281 7. References 1283 [Atk95a] Atkinson, R., "Security Architecture for the Internet 1284 Protocol", RFC 1825, August 1995. 1286 [Atk95b] Atkinson, R., "IP Authentication Header", RFC 1826, August 1287 1995. 1289 [Atk95c] Atkinson, R., "IP Encapsulating Security Payload (ESP)", 1290 RFC 1827, August 1995. 1292 [Brad89] Braden, R., "Requirements for Internet Hosts -- 1293 Communication Layers", RFC 1122, October 1989. 1295 [Deer89] Deering, S., "Host Extensions for IP Multicasting", RFC 1296 1112, August 1989. 1298 [Deer90] Deering, S., Cheriton, D., "Multicast Routing in Datagram 1299 Internetworks and Extended LANs", ACM Transactions on 1300 Computer Systems, Vol. 8, No. 2, May 1990, pp. 85-110. 1302 [Deer91] Deering, S., "Multicast Routing in a Datagram 1303 Internetwork", PhD thesis, Electric Engineering Dept., 1304 Stanford University, December 1991. 1306 [Fenn96] Fenner, W., Casner, S., "A "traceroute" facility for IP 1307 Multicast", Work In Progress, November 1996. 1309 [Fenn97] Fenner, W., "Internet Group Management Protocol, Version 1310 2", Work In Progress, January 1997. 1312 [Full93] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 1313 Inter-Domain Routing (CIDR): an Address Assignment and 1314 Aggregation Strategy", RFC 1519, September 1993. 1316 [Mogu90] Mogul, J., Deering, S., "Path MTU Discovery", RFC 1191, 1317 November 1990. 1319 [Perk96] Perkins, C., IP Encapsulation within IP, RFC 2003, October 1320 1996. 1322 [Perl92] Perlman, R., Interconnections: Bridges and Routers, 1323 Addison-Wesley, May 1992, pp. 205-211. 1325 [Rekh93] Rekhter, Y., and T. Li, "An Architecture for IP Address 1326 Allocation with CIDR", RFC 1518, September 1993. 1328 [Reyn94] Reynolds, J., Postel, J., "Assigned Numbers", STD 0002, 1329 October 1994. 1331 [Thal97] Thaler, D., "Distance-Vector Multicast Routing Protocol 1332 MIB", Work In Progress, April 1997. 1334 [Wait88] Waitzman, D., Partridge, C., Deering, S., "Distance Vector 1335 Multicast Routing Protocol", RFC 1075, November 1988. 1337 8. Author's Address 1339 Thomas Pusateri 1340 Juniper Networks, Inc. 1341 385 Ravendale Dr. 1342 Moutain View, CA 94043 1343 Phone: (919) 558-0700 1344 EMail: pusateri@juniper.net 1346 9. Acknowledgments 1348 The author would like to acknowledge the original designers of the 1349 protocol, Steve Deering, Craig Partridge, and David Waitzman. 1350 Version 3 of the protocol would not have been possible without the 1351 original work of Ajit Thyagarajan and the ongoing (and seemingly 1352 endless) work of Bill Fenner. Credit also goes to Danny Mitzel for 1353 the careful review of this document and Nitin Jain, Dave LeRoy, 1354 Charles Mumford, Ravi Shekhar, Shuching Shieh, and Dave Thaler for 1355 their helpful comments. 1357 10. Appendix A - Constants & Configurable Parameters 1359 The following table provides a summary of the DVMRP timing 1360 parameters: 1362 Parameter Value (seconds) 1363 ----------------------------------------------------- 1364 Probe Interval 10 1365 Neighbor Time-out Interval 35 1366 Minimum Flash Update Interval 5 1367 Route Report Interval 60 1368 Route Replacement Time 140 1369 Prune Lifetime variable (< 2 hours) 1370 Prune Retransmission Time 3 with exp. back-off 1371 Graft Retransmission Time 5 with exp. back-off 1372 ----------------------------------------------------- 1374 Table 2 - Parameter Summary 1376 11. Appendix B - Tracing and Troubleshooting support 1378 There are several packet types used to gather DVMRP specific 1379 information. They are generally used for diagnosing problems or 1380 gathering topology information. The first two messages are now 1381 obsoleted and should not be used. The remaining two messages provide 1382 a request/response mechanism to determine the versions and 1383 capabilities of a particular DVMRP router. 1385 Code Packet Type Description 1386 ----------------------------------------------------------- 1387 3 DVMRP Ask Neighbors Obsolete 1388 4 DVMRP Neighbors Obsolete 1389 5 DVMRP Ask Neighbors 2 Request Neighbor List 1390 6 DVMRP Neighbors 2 Respond with Neighbor List 1391 ----------------------------------------------------------- 1393 Table 3 - Debugging Packet Types 1395 11.1. DVMRP Ask Neighbors2 1397 The Ask Neighbors2 packet is a unicast request packet directed at a 1398 DVMRP router. The destination should respond with a unicast 1399 Neighbors2 message back to the sender of the Ask Neighbors2 message. 1401 0 8 16 31 1402 +---------+---------+--------------------+ 1403 | Type | Code | Checksum | 1404 |(0x13) | (0x5) | | 1405 +---------+---------+----------+---------+ 1406 | Reserved | Minor | Major | 1407 | | Version |Version | 1408 +-------------------+----------+---------+ 1410 Figure 8 - Ask Neighbors 2 Packet Format 1412 11.2. DVMRP Neighbors2 1414 The format of a Neighbors2 response packet is shown below. This is 1415 sent as a unicast message back to the sender of an Ask Neighbors2 1416 message. There is a common header at the top followed by the routers 1417 capabilities. One or more sections follow that contain an entry for 1418 each logical interface. The interface parameters are listed along 1419 with a variable list of neighbors learned on each interface. 1421 If the interface is down or disabled, list a single neighbor with an 1422 address of 0.0.0.0 for physical interfaces or the remote tunnel 1423 endpoint address for tunnel pseudo-interfaces. 1425 0 8 16 31 1426 +-----------+--------------+--------------------------+ 1427 | Type | Code | Checksum | 1428 | (0x13) | (0x6) | | 1429 +-----------+--------------+------------+-------------+ 1430 | Reserved | Capabilities | Minor | Major | 1431 | | | Version | Version | 1432 +-----------+--------------+------------+-------------+ 1433 | | 1434 | Local Addr 1 | 1435 +-----------+--------------+------------+-------------+ 1436 | | | | | 1437 | Metric 1 | Threshold 1 | Flags 1 | Nbr Count 1 | 1438 +-----------+--------------+------------+-------------+ 1439 | | 1440 | Nbr 1 | 1441 +-----------------------------------------------------+ 1442 | | 1443 | ... | 1444 +-----------------------------------------------------+ 1445 | | 1446 | Nbr m | 1447 +-----------------------------------------------------+ 1448 | | 1449 | Local Addr N | 1450 +-----------+--------------+------------+-------------+ 1451 | | | | | 1452 | Metric N | Threshold N | Flags N | Nbr Count N | 1453 +-----------+--------------+------------+-------------+ 1454 | | 1455 | Nbr 1 | 1456 +-----------------------------------------------------+ 1457 | | 1458 | ... | 1459 +-----------------------------------------------------+ 1460 | | 1461 | Nbr k | 1462 +-----------------------------------------------------+ 1464 Figure 9 - Neighbors 2 Packet Format 1466 The capabilities of the local router are defined as follows: 1468 Bit Flag Description 1469 --------------------------------------------------- 1471 0 Leaf This is a leaf router 1473 1 Prune This router understands pruning 1475 2 GenID This router sends Generation Id's 1477 3 Mtrace This router handles Mtrace requests 1479 4 Snmp This router supports the DVMRP MIB 1480 --------------------------------------------------- 1482 Table 4 - DVMRP Router Capabilities 1484 The flags associated with a particular interface are: 1486 Bit Flag Description 1487 ---------------------------------------------------------- 1489 0 Tunnel Neighbor reached via tunnel 1491 1 Source Route Tunnel uses IP source routing 1493 2 Reserved No longer used 1495 3 Reserved No longer used 1497 4 Down Operational status down 1499 5 Disabled Administrative status down 1501 6 Querier Querier for interface 1503 7 Leaf No downstream neighbors on interface 1504 ---------------------------------------------------------- 1506 Table 5 - DVMRP Interface flags 1508 12. Appendix C - Version Compatibility 1510 There have been two previous major versions of DVMRP with 1511 implementations still in circulation. If the receipt of a Probe 1512 message reveals a major version of 1 or 2, then it can be assumed 1513 that this neighbor does not support pruning or the use of the 1514 Generation ID in the Probe message. However, since these older 1515 implementations are known to safely ignore the Generation ID and 1516 neighbor information in the Probe packet, it is not necessary to 1517 send specially formatted Probe packets to these neighbors. 1519 There were three minor versions (0, 1, and 2) of major version 3 1520 that did support pruning but did not support the Generation ID or 1521 capability flags. These special cases will have to be accounted 1522 for. 1524 Any other minor versions of major version 3 closely compare to 1525 this specification. 1527 In addition, cisco Systems is known to use their software major 1528 and minor release number as the DVMRP major and minor version 1529 number. These will typically be 10 or 11 for the major version 1530 number. Pruning was introduced in Version 11. 1532 Implementations prior to this specification may not wait to send 1533 route reports until probe messages have been received with the 1534 routers address listed. Reports SHOULD be sent to these neighbors 1535 without first requiring a received probe with the routers address 1536 in it as well as reports from these neighbors SHOULD be accepted. 1537 Although, this allows one-way neighbor relationships to occur, it 1538 does maintain backward compatibility. 1540 Implementations that do not monitor Generation ID changes can 1541 create more noticeable black holes when using long prune lifetimes 1542 such as ~2 hours. This happens when a long prune is sent upstream 1543 and then the router that sent the long prune restarts. If the 1544 upstream router ignores the new Generation ID, the prune received 1545 by the upstream router will not be flushed and the downstream 1546 router will have no knowledge of the upstream prune. For this 1547 reason, prunes sent upstream to routers that are known to ignore 1548 Generation ID changes should have short lifetimes. 1550 If the router must run IGMP version 1 on an interface for 1551 backwards compatibility, DVMRP must elect the DVMRP router with 1552 the highest IP address as the IGMP querier. 1554 Some implementations of tools that send DVMRP Ask Neighbors2 1555 requests and receive Neighbors2 response messages require a 1556 neighbor address of 0.0.0.0 when no neighbors are listed in the 1557 response packet. (Mrinfo) 1558 Table of Contents 1560 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 1561 1.1. Reverse Path Multicasting . . . . . . . . . . . . . . . . 2 1562 1.2. IP-IP Tunnels . . . . . . . . . . . . . . . . . . . . . . 2 1563 1.3. Document Overview . . . . . . . . . . . . . . . . . . . . 3 1564 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 3 1565 2.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 3 1566 2.2. Source Location . . . . . . . . . . . . . . . . . . . . . 4 1567 2.3. Dependent Downstream Routers . . . . . . . . . . . . . . 5 1568 2.4. Designated Forwarder . . . . . . . . . . . . . . . . . . 5 1569 2.5. Building Multicast Trees . . . . . . . . . . . . . . . . 6 1570 2.6. Pruning Multicast Trees . . . . . . . . . . . . . . . . . 7 1571 2.7. Grafting Multicast Trees . . . . . . . . . . . . . . . . 7 1572 3. Detailed Protocol Operation . . . . . . . . . . . . . . . . 8 1573 3.1. Protocol Header . . . . . . . . . . . . . . . . . . . . . 8 1574 3.2. Probe Messages . . . . . . . . . . . . . . . . . . . . . 9 1575 3.3. Building Forwarding Cache Entries . . . . . . . . . . . . 14 1576 3.4. Route Exchange . . . . . . . . . . . . . . . . . . . . . 15 1577 3.5. Pruning . . . . . . . . . . . . . . . . . . . . . . . . . 23 1578 3.6. Grafting . . . . . . . . . . . . . . . . . . . . . . . . 27 1579 3.7. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 31 1580 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 1581 5. Network Management Considerations . . . . . . . . . . . . . 31 1582 6. Security Considerations . . . . . . . . . . . . . . . . . . 32 1583 7. References . . . . . . . . . . . . . . . . . . . . . . . . 32 1584 8. Author's Address . . . . . . . . . . . . . . . . . . . . . 33 1585 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 33 1586 10. Appendix A - Constants & Configurable Parameters . . . . . 35 1587 11. Appendix B - Tracing and Troubleshooting support . . . . . 36 1588 11.1. DVMRP Ask Neighbors2 . . . . . . . . . . . . . . . . . . 36 1589 11.2. DVMRP Neighbors2 . . . . . . . . . . . . . . . . . . . . 37 1590 12. Appendix C - Version Compatibility . . . . . . . . . . . . 41