idnits 2.17.1 draft-ietf-idmr-dvmrp-v3-04.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-26) 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 385: '...igured for DVMRP SHOULD have an interv...' RFC 2119 keyword, line 386: '... time-out interval SHOULD be set at 35...' RFC 2119 keyword, line 388: '...y multicast routers. These values MUST...' RFC 2119 keyword, line 413: '... the future and MUST be set to 0. Bit...' RFC 2119 keyword, line 414: '...earch topic. It MUST be set to 0. Bi...' (15 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 315 has weird spacing: '...ets are encap...' == Line 346 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 every interface running DVMRP 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 (February 1997) is 9932 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 625 ** 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. 'Fen96a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Fen96b' ** 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. 'Thal96' ** 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 February 1997 5 draft-ietf-idmr-dvmrp-v3-04 Expires: August 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 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 unicast routing 55 table of known source networks. If the datagram arrives on an 56 interface that would be used to transmit unicast datagrams back to 57 the source, then it is forwarded to the appropriate list of 58 downstream interfaces. Otherwise, it is not on the optimal delivery 59 tree and should be discarded. In this way duplicate packets can be 60 filtered when loops exist in the network topology. The source 61 specific delivery trees are automatically pruned back as group 62 membership changes or leaf routers determine that no group members 63 are present. This keeps the delivery trees to the minimum branches 64 necessary to reach all of the group members. New sections of the tree 65 can also be added dynamically as new members join the multicast group 66 by grafting 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. In this 120 way, Neighbor DVMRP routers can ensure that they are seen by each 121 other. Care must be taken to inter-operate with older implementations 122 of DVMRP that do not include this list of neighbors. It can be 123 assumed that older implementations of DVMRP will safely ignore this 124 list of neighbors in the Probe message. Therefore, it is not 125 necessary to send both old and new types of Neighbor Probes. 127 2.2. Source Location 129 When an IP Multicast datagram is received by a router running DVMRP, 130 it first looks up the source network in the DVMRP routing table. The 131 interface of the next hop of packets sent back to the source of the 132 datagram is called the upstream interface. If the datagram arrived 133 on the correct upstream interface, then it is a candidate for 134 forwarding to one or more downstream interfaces. If the datagram did 135 not arrive on the anticipated upstream interface, it is discarded. 136 This check is known as a reverse path forwarding check and must be 137 performed by all DVMRP routers. 139 In order to ensure that all DVMRP routers have a consistent view of 140 the unicast path back to a source, a unicast routing table is 141 propagated to all DVMRP routers as an integral part of the protocol. 142 Each router advertises the network number and mask of the interfaces 143 it is directly connected to as well as relaying the routes received 144 from neighbor routers. DVMRP requires an interface metric to be 145 configured on all physical and tunnel interfaces. When a route is 146 received, the metric of the upstream interface over which the 147 datagram was received must be added to the metric of the route being 148 propagated. This adjusted metric should be computed before the route 149 is compared to the metric of the current next hop gateway. 151 Although there is certainly additional overhead associated with 152 propagating a separate unicast routing table, it does provide two 153 nice features. First, since all DVMRP routers are using the same 154 unicast routing protocol, there are no inconsistencies between 155 routers when determining the upstream interface (aside from normal 156 convergence issues related to distance vector routing protocols). By 157 placing the burden of synchronization on the protocol as opposed to 158 the network manager, DVMRP reduces the risk of creating routing loops 159 or black holes due to disagreement between neighbor routers on the 160 upstream interface. 162 Second, by propagating its own unicast 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 unicast routes in DVMRP provides one other important 176 feature. DVMRP uses the unicast route exchange as a mechanism for 177 upstream routers to determine if any downstream routers depend on 178 them for forwarding from particular source networks. DVMRP 179 accomplishes this by using a technique called "Poison Reverse". If a 180 downstream router selects an upstream router as the best next hop to 181 a particular source network, this is indicated by echoing back the 182 route to the upstream router with a metric equal to the original 183 metric plus infinity. When the upstream router receives the report 184 and sees a metric that lies between infinity and twice infinity, it 185 can then add the downstream router from which it received the report 186 to a list of dependent 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. Multi-access Networks 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 unicast route exchange. When two routers on a 200 multi-access network exchange source networks, each of the routers 201 will know the others metric back to each source network. Therefore, 202 of all the DVMRP routers on a shared network, the router with the 203 lowest metric to a source network is responsible for forwarding data 204 on to the shared network. If two or more routers have an equally low 205 metric, the router with the lowest IP address becomes the designated 206 forwarder for the network. 208 2.5. Building Multicast Trees 210 As previously mentioned, when an IP multicast datagram arrives, the 211 upstream interface is determined by looking up the interface that 212 would be used if a datagram was being sent back to the source of the 213 datagram. If the upstream interface is correct, then a DVMRP router 214 will forward the datagram to a list of downstream interfaces. 216 2.5.1. Adding Leaf Networks 218 Initially, the DVMRP router must consider all of the remaining IP 219 multicast capable interfaces (including tunnels) on the router. If 220 the downstream interface under consideration is a leaf network (has 221 no dependent downstream neighbors for the source network), then the 222 IGMP local group database must be consulted. DVMRP routers can easily 223 determine if a directly attached network is a leaf network by keeping 224 a list of all routers from which DVMRP Router Probe messages have 225 been received on the interface. Obviously, it is necessary to refresh 226 this list and age out entries received from routers that are no 227 longer being refreshed. The IGMP local group database is maintained 228 by an elected IP multicast router on each physical, multicast capable 229 network. The details of the election procedure are discussed in 230 [Fen96a]. If the destination group address is listed in the local 231 group database, and the router is the designated forwarder for the 232 network, then the interface should be included in the list of 233 downstream interfaces. If there are no group members on the 234 interface, then the interface can be removed from the outgoing 235 interface list. 237 2.5.2. Adding Non-Leaf Networks 239 Initially, all non-leaf networks should be included in the downstream 240 interface list when a forwarding cache entry is first being created. 241 This allows all downstream routers to be aware of traffic destined 242 for a particular (source, group) pair. The downstream routers will 243 then have the option to send prunes and grafts for this (source, 244 group) pair as requirements change from their respective downstream 245 routers and local group members. 247 2.6. Pruning Multicast Trees 249 As mentioned above, routers at the edges with leaf networks will 250 remove their leaf interfaces that have no group members associated 251 with an IP multicast datagram. If a router removes all of its 252 downstream interfaces, it can notify the upstream router that it no 253 longer wants traffic destined for a particular (source, group) pair. 254 This is accomplished by sending a DVMRP Prune message upstream to the 255 router it expects to forward datagrams from a particular source. 257 Recall that a downstream router will inform an upstream router that 258 it depends on the upstream router to receive datagrams from 259 particular source networks by using the "Poison Reverse" technique 260 during the exchange of unicast routes. This method allows the 261 upstream router to build a list of downstream routers on each 262 interface that are dependent upon it for datagrams from a particular 263 source network. If the upstream router receives prune messages from 264 each one of the dependent downstream routers on an interface, then 265 the upstream router can in turn remove this interface from its 266 downstream interface list. If the upstream router is able to remove 267 all of its downstream interfaces in this way, it can then send a 268 DVMRP Prune message to its upstream router. This continues until the 269 unneeded branches are removed from the delivery tree. 271 In order to remove old prune state information for (source, group) 272 pairs that are no longer active, it is necessary to limit the life of 273 a prune and periodically resume the flooding procedure. Inside the 274 prune message is a prune lifetime. This indicates the length of time 275 that the prune should remain in effect. When the prune lifetime 276 expires, the interface is joined back onto the multicast delivery 277 tree. If unwanted multicast datagrams continue to arrive, the prune 278 mechanism will be re-initiated and the cycle will continue. If all 279 of the downstream interfaces are removed from a multicast delivery 280 tree causing a DVMRP Prune message to be sent upstream, the lifetime 281 of the prune sent will be equal to the minimum of the remaining prune 282 lifetimes of the downstream interfaces. 284 2.7. Grafting Multicast Trees 286 Once a tree branch has been pruned from a multicast delivery tree, 287 packets from the corresponding (source, group) pair will no longer be 288 forwarded. However, since IP multicast supports dynamic group 289 membership, new hosts may join the multicast group. In this case, 290 DVMRP routers use Grafts to undo the prunes that are in place from 291 the host back on to the multicast delivery tree. A router will send 292 a Graft message to its upstream neighbor if a group join occurs for a 293 group that the router has previously sent a prune. Separate Graft 294 messages must be sent to the appropriate upstream neighbor for each 295 source that has been pruned. Since there would be no way to tell if 296 a Graft message sent upstream was lost or the source simply quit 297 sending traffic, it is necessary to acknowledge each Graft message 298 with a DVMRP Graft Ack message. If an acknowledgment is not received 299 within a Graft Time-out period, the Graft message should be 300 retransmitted. Duplicate Graft Ack messages should simply be ignored. 301 The purpose of the Graft Ack message is to simply acknowledge the 302 receipt of a Graft message. It does not imply that any action was 303 taken as a result of receiving the Graft message. Therefore, all 304 Graft messages should be acknowledged whether or not they cause an 305 action on the receiving router. 307 3. Detailed Protocol Operation 309 This section contains a detailed description of DVMRP. It covers 310 sending and receiving of DVMRP messages as well as the generation and 311 maintenance of IP Multicast forwarding cache entries. 313 3.1. Protocol Header 315 DVMRP packets are encapsulated in IP datagrams, with an IP protocol 316 number of 2 (IGMP) as specified in the Assigned Numbers RFC [Reyn94]. 317 All fields are transmitted in Network Byte Order. DVMRP packets use a 318 common protocol header that specifies the IGMP [Fen96a] Packet Type 319 as hexadecimal 0x13 (DVMRP). A diagram of the common protocol header 320 follows: 322 0 8 16 31 323 +---------+---------+--------------------+ 324 | Type | Code | Checksum | 325 |(0x13) | | | 326 +---------+---------+----------+---------+ 327 | Reserved | Minor | Major | 328 | | Version |Version | 329 +-------------------+----------+---------+ 331 Figure 1 - Common Protocol Header 333 A Major Version of 3 and a Minor Version of 0xFF should be used to 334 indicate compliance with this specification. The value of the Code 335 field determines the DVMRP packet type. Currently, there are codes 336 allocated for DVMRP protocol message types as well as protocol 337 analysis and troubleshooting packets. The protocol message Codes 338 are: 340 Code Packet Type Description 341 ---------------------------------------------------------------- 342 1 DVMRP Probe for neighbor discovery 343 2 DVMRP Report for unicast route exchange 344 7 DVMRP Prune for pruning multicast delivery trees 345 8 DVMRP Graft for grafting multicast delivery trees 346 9 DVMRP Graft Ack for acknowledging graft messages 347 ---------------------------------------------------------------- 349 Table 1 - Standard Protocol Packet Types 351 There are additional codes used for protocol analysis and 352 troubleshooting. These codes are discussed in Appendix B. The 353 Checksum is the 16-bit one's complement of the one's complement sum 354 of the DVMRP message. The checksum of the DVMRP message should be 355 calculated with the checksum field set to zero. 357 3.2. Probe Messages 359 When a DVMRP router is configured to run on an interface (physical or 360 tunnel), it sends local IP Multicast discovery packets to inform 361 other DVMRP routers that it is operational. These discovery packets 362 are called DVMRP Probes and they serve three purposes. 364 1. Probes provide a mechanism for DVMRP routers to locate each other. 365 DVMRP sends a list of detected neighbors in the Probe message. 366 This list of DVMRP neighbors provides a foundation for the 367 dependent downstream neighbor list. If no DVMRP neighbors are 368 found, the network is considered to be a leaf network. A DVMRP 369 router should discard all other protocol packets from a neighbor 370 until it has seen its own address in the neighbors Probe list. 371 (See Appendix C for exceptions.) 373 2. Probes provide a way for DVMRP routers to determine the 374 capabilities of each other. This may be deduced from the major and 375 minor version numbers in the Probe packet or directly from the 376 capability flags. These flags were first introduced to allow 377 optional protocol features. This specification now mandates the 378 use of Generation Id's and pruning and, therefore, provides no 379 optional capabilities. Other capability flags were used for 380 tracing and troubleshooting and are no longer a part of the actual 381 protocol. 383 3. Probes provide a keep-alive function in order to quickly detect 384 neighbor loss. DVMRP probes sent on each multicast capable 385 interface configured for DVMRP SHOULD have an interval of 10 386 seconds. The neighbor time-out interval SHOULD be set at 35 387 seconds. This allows fairly early detection of a lost neighbor yet 388 provides tolerance for busy multicast routers. These values MUST 389 be coordinated between all DVMRP routers on a physical network 390 segment. 392 3.2.1. Router Capabilities 394 In the past, there have been many versions of DVMRP in use with a 395 wide range of capabilities. Practical considerations require a 396 current implementation to inter-operate with these older 397 implementations that don't formally specify their capabilities and 398 are not compliant with this specification. For instance, for major 399 versions less than 3, it can be assumed that the neighbor does not 400 support pruning. The formal capability flags were first introduced 401 in an well known implementation (Mrouted version 3.5) in an attempt 402 to take the guess work out which features are supported by a 403 neighbor. Many of these flags are no longer necessary since they are 404 now a required part of the protocol, however, special consideration 405 is necessary to not confuse older implementations that expect these 406 flags to be set. Appendix C was written to assist with these and 407 other backward compatibility issues. 409 Three of the flags were used for actual protocol operation. The 410 other two assigned flags were used for troubleshooting purposes which 411 should be documented in a separate specification. All of the bits 412 marked "U" in the Figure below are now unused. They may be defined in 413 the future and MUST be set to 0. Bit position 0 is the LEAF bit which 414 is a current research topic. It MUST be set to 0. Bit positions 1, 415 2, and 3 MUST be set to 1 for backward compatibility. They were used 416 to specify the PRUNE, GENID, and MTRACE bits. The first two, PRUNE 417 and GENID, are now required features. The MTRACE bit must be set so 418 existing implementations will not assume this neighbor does not 419 support multicast trace-route [Fen96b]. However, since this bit is 420 now reserved and set to 1, newer implementations should not use this 421 bit in the Probe message to determine if multicast trace-route is 422 supported by a neighbor. Instead, the M bit should only be used in a 423 Neighbors2 message as described in Appendix B. The bit marked S 424 stands for SNMP capable. This bit is used by troubleshooting 425 applications and should only be tested in the Neighbors2 message. 427 0 8 9 10 S M G P L 428 +--------------------------+----+----+----+----+----+----+----+----+ 429 | Reserved | U | U | U | U | 1 | 1 | 1 | L | 430 +--------------------------+----+----+----+----+----+----+----+----+ 432 Figure 2 - Probe Capability Flags 434 3.2.2. Generation ID 436 If a DVMRP router is restarted, it will want to learn all of the 437 routes known by its neighbors without having to wait for an entire 438 report interval to pass. In order for the neighbor to detect that the 439 router has restarted, a non-decreasing number is placed in the 440 periodic probe message called the generation ID. When a neighbor 441 detects an increase in the generation ID of a router, it should re- 442 send its entire unicast routing table to the router. 444 If a change in generation ID is detected, any prune information 445 received from the router is no longer valid and should be flushed. 446 If this prune state has caused prune information to be sent upstream, 447 a graft will need to be sent upstream just as though a new member has 448 joined below. Once data begins to be delivered downstream, if the 449 downstream router again decides to be pruned from the delivery tree, 450 a new prune can be sent upstream at that time. 452 A time of day clock provides a good source for a non-decreasing 32 453 bit integer. 455 3.2.3. Neighbor Addresses 457 As a DVMRP router sees Probe messages from its DVMRP neighbors, it 458 records the neighbor addresses on each interface and places them in 459 the Probe message sent on the particular interface. This allows the 460 neighbor router to know that its probes have been received by the 461 sending router. 463 In order to minimize one-way neighbor relationships, a router MUST 464 delay sending poison route reports directly to a neighbor until the 465 neighbor includes the routers address in its probe messages. 467 Implementations written before this specification will not wait 468 before sending reports nor will they ignore reports sent. Therefore, 469 reports from these implementations SHOULD be accepted whether or not 470 a probe with the routers address has been received. 472 3.2.4. Probe Packet Format 474 The Probe packet is variable in length depending on the number of 475 neighbor IP addresses included. The length of the IP packet can be 476 used to determine the number of neighbors in the Probe message. The 477 current Major Version is 3. To maintain compatibility with previous 478 versions, implementations of Version 3 must include pruning and 479 grafting of multicast trees. Non-pruning implementations SHOULD NOT 480 be implemented at this time. 482 7 15 23 31 483 +---------+--------------+--------------------+ 484 | Type | Code | Checksum | 485 | (0x13) | (0x1) | | 486 +---------+--------------+----------+---------+ 487 | | | | | 488 |Reserved | Capabilities | Minor | Major | 489 +---------+--------------+----------+---------+ 490 | | 491 | Generation ID | 492 +---------------------------------------------+ 493 | | 494 | Neighbor IP Address 1 | 495 +---------------------------------------------+ 496 | | 497 | Neighbor IP Address 2 | 498 +---------------------------------------------+ 499 | | 500 | ... | 501 +---------------------------------------------+ 502 | | 503 | Neighbor IP Address N | 504 +---------------------------------------------+ 506 Figure 3 - DVMRP Probe Packet Format 508 3.2.5. Designated Router Election 510 Since it is wasteful to have more than a single router sending IGMP 511 Host Membership Queries on a given physical network, a single router 512 on each physical network is elected as the Designated Querier. This 513 election used to be a part of DVMRP. However, this is now handled as 514 a part of the IGMP vesion 2 protocol. Therefore, DVMRP Version 3 515 requires the use of IGMP Version 2 or later specifying that the 516 Designated Querier election is performed as a part of IGMP. 518 Even though only one router will act as the designated querier, all 519 DVMRP routers must listen to IGMP Host Membership Reports and keep a 520 local group database. 522 3.3. Building Forwarding Cache Entries 524 In order to create optimal multicast delivery trees, DVMRP was 525 designed to keep separate forwarding cache entries for each (source 526 network, destination group) pair. Because the possible combinations 527 of these is quite large, forwarding cache entries are generated on 528 demand as data arrives at a multicast router. Since the IP forwarding 529 decision is made on a hop by hop basis (as with the unicast case), it 530 is imperative that each multicast router has a consistent view of the 531 reverse path back to the source network. 533 3.3.1. Determining the upstream interface 535 When a multicast packet arrives, a DVMRP router will use the DVMRP 536 unicast routing table to determine which interface leads back to the 537 source. If the packet did not arrive on that interface, it should be 538 discarded without further processing. Each multicast forwarding entry 539 should cache the upstream interface for a particular source host or 540 source network after looking this up in the DVMRP unicast routing 541 table. 543 3.3.2. Determining the downstream interface list 545 The downstream interface list is built from the remaining list of 546 multicast capable interfaces. Any interfaces designated as leaf 547 networks that do not have members of the particular multicast group 548 can be automatically removed from list of downstream interfaces. The 549 remaining interfaces will either have downstream DVMRP routers or 550 directly attached group members. These interfaces may be removed in 551 the future if it is determined that there are no group members 552 anywhere along the entire tree branch. 554 3.4. Unicast Route Exchange 556 It was mentioned earlier that since not all IP routers support IP 557 multicast forwarding, it is necessary to tunnel IP multicast 558 datagrams through these routers. One effect of using these 559 encapsulated tunnels is that IP multicast traffic may not be aligned 560 with IP unicast traffic. This means that a multicast datagram from a 561 particular source can arrive on a different (logical) interface than 562 the expected upstream interface based on traditional unicast routing. 564 The unicast routing information propagated by DVMRP is used for 565 determining the reverse path back to the source of multicast traffic. 566 Tunnel pseudo-interfaces are considered to be distinct for the 567 purpose of determining upstream and downstream interfaces. The 568 routing information that is propagated by DVMRP contains a list of 569 unicast source networks and an appropriate metric. The metric used is 570 a hop count which is incremented by the cost of the incoming 571 interface metric. Traditionally, physical interfaces use a metric of 572 1 while the metric of a tunnel interface varies with the distance and 573 bandwidth in the path between the two tunnel endpoints. Users are 574 encouraged to configure tunnels with the same metric in each 575 direction to create symmetric routing and provide for easier problem 576 determination although the protocol does not strictly enforce this. 578 Implementations may wish to provide a mechanism to aggregate source 579 networks to reduce the size of the unicast routing table. All 580 implementations should be able to accept reports for aggregated 581 source networks in accordance with Classless Inter-Domain Routing 582 (CIDR) as described in [Rekh93] and [Full93]. 584 There are two places where aggregation is particularly useful. 586 1. At organizational boundaries to limit the number of source 587 networks advertised out of the organization. 589 2. Within an organization to summarize non-local routing information 590 by using a default (0/0) route. 592 3.4.1. Route Packing and Ordering 594 Since DVMRP Route Reports may need to refresh several thousand routes 595 each report interval, routers MUST attempt to spread the routes 596 reported across the whole route update interval. This reduces the 597 chance of synchronized route reports causing routers to become 598 overwhelmed for a few seconds each report interval. Since the route 599 report interval is 60 seconds, it is suggested that the total number 600 routes being updated be split across multiple Route Reports sent at 601 regular intervals. Their was an earlier requirement that Route 602 Reports MUST contain source network/mask pairs sorted first by 603 increasing network mask and then by increasing source network. This 604 restriction has been lifted. Implementations conforming to this 605 specification MUST be able to receive Route Reports containing any 606 mixture of network masks and source networks. 608 In order to pack more source networks into a route report, source 609 networks are often represented by less than 4 octets. The number of 610 non-zero bytes in the mask value is used to determine the number of 611 octets used to represent each source network within that particular 612 mask value. For instance if the mask value of 255.255.0.0 is being 613 reported, the source networks would only contain 2 octets each. DVMRP 614 assumes that source networks will never be aggregated into networks 615 whose prefix length is less than 8. Therefore, it does not carry the 616 first octet of the mask in the Route Report since, given this 617 assumption, the first octet will always be 0xFF. This means that the 618 netmask value will always be represented in 3 octets. This method of 619 specifying source network masks is compatible with techniques 620 described in [Rekh93] and [Full93] to group traditional Class C 621 networks into super-nets and to allow different subnets of the same 622 Class A network to be discontinuous. In this notation, the default 623 route is represented as the least three significant octets of the 624 netmask [00 00 00], followed by one octet for the network number 625 [00]. 627 3.4.2. Unicast Route Metrics 629 For each source network reported, a route metric is associated with 630 the unicast route being reported. The metric is the sum of the 631 interface metrics between the router originating the report and the 632 source network. For the purposes of DVMRP, the Infinity metric is 633 defined to be 32. This limits the breadth across the whole DVMRP 634 network and is necessary to place an upper bound on the convergence 635 time of the protocol. 637 As seen in the packet format below, Route Reports do not contain a 638 count of the number of routes reported for each netmask. Instead, the 639 high order bit of the metric is used to signify the last route being 640 reported for a particular mask value. If a metric is read with the 641 high order bit of the 8-bit value set and if the end of the message 642 has not been reached, the next value will be a new netmask to be 643 applied to the subsequent list of routes. 645 3.4.3. Unicast Route Dependencies 647 In order for pruning to work correctly, each DVMRP router needs to 648 know which downstream routers depend on it for receiving datagrams 649 from particular source networks. Initially, when a new datagram 650 arrives from a particular source/group pair, it is flooded to all 651 downstream interfaces that have DVMRP neighbors who have indicated a 652 dependency on the receiving DVMRP router for that particular source. 653 A downstream interface can only be removed when it has received Prune 654 messages from each of the dependent routers on that interface. Each 655 downstream router uses Poison Reverse to indicate to the upstream 656 router which source networks it expects to receive from the upstream 657 router. The downstream router indicates this by echoing back the 658 source networks it expects to receive from the upstream router with 659 infinity added to the advertised metric. This means that the legal 660 values for the metric now become between 1 and (2 x Infinity - 1) or 661 1 and 63. Values between 1 and 31 indicate reachable unicast source 662 networks. The value Infinity (32) indicates the source network is not 663 reachable. Values between 33 and 63 indicate that the downstream 664 router originating the Report is depending upon the upstream router 665 to provide multicast datagrams from the corresponding source network. 667 3.4.4. Sending Route Reports 669 All of the active routes MUST be advertised over every interface 670 running DVMRP each Route Report Interval. In addition, flash updates 671 MAY be sent as needed but any given route MUST not be advertised more 672 often than the Minimum Flash Update Interval (5 seconds). Flash 673 updates can reduce the chances of routing loops and black holes 674 occurring when source networks become unreachable through a 675 particular path. Flash updates need only contain the source networks 676 that have changed. It is not necessary to report all of the source 677 networks from a particular mask value when sending an update. 679 Route Reports containing downstream dependent "poison" metrics should 680 be sent directly to the neighbors unicast address. These reports 681 should not be sent to a neighbor until a router has seen its own 682 address in the neighbors Probe router list. See Appendix C for 683 exceptions. These Reports should be refreshed at the standard Route 684 Update Interval. 686 3.4.5. Receiving Route Reports 688 After receiving a route report, a check should be made to verify it 689 is from a known neighbor. Neighbors are learned via received Probe 690 messages which also indicate the capabilities of the neighbor. 691 Therefore, route reports from unknown neighbors are discarded. 693 Each route in the report is then parsed and processed according to 694 the following rules: 696 A. If the route is new and the metric is less than infinity, the 697 route should be added. 699 B. If the route already exists, several checks must be performed. 701 1. New metric < infinity 703 a. New metric > existing metric 705 If the new metric is greater than the existing metric then 706 check to see if the same neighbor is reporting the route. If 707 so, update the metric and flash update the route. 708 Otherwise, discard the route. 710 b. New metric < existing metric 712 Update the metric for the route and if the neighbor 713 reporting the route is different, update the upstream 714 neighbor in the routing table. Flash update the route to 715 downstream neighbors and if the neighbor changed, a flash 716 update should be sent to the new neighbor indicating 717 downstream dependence and to the existing neighbor 718 withdrawing downstream dependence of the route. 720 c. New metric = existing metric 722 If the neighbor reporting the route is the same as the 723 existing route, then simply refresh the route. If the new 724 neighbor has a lower IP address, then update the route. 725 Flash updates should be sent to the new and old neighbors to 726 notify them of changes in downstream dependencies. 728 2. New metric = infinity 730 a. New next hop = existing next hop 732 If the existing metric was less than infinity, the route is 733 now unreachable. Update the route and possibly update 734 neighbors as well. 736 If the existing metric was between infinity and 2 x 737 infinity, the neighbor used to be a dependent downstream 738 router but is no longer. Note this dependency change and 739 any Prunes that it may trigger. 741 b. New next hop != existing next hop 743 The route can be ignored since the existing next hop has a 744 metric better than or equal to this next hop. 746 3. infinity < New metric < 2 x infinity 748 If the receiving router is not the designated forwarder for the 749 source network on the interface the report was received, the 750 poison report should be ignored. Otherwise, the neighbor 751 considers the receiving router to be upstream for the route and 752 is indicating it is dependent on the receiving router. 754 a. Neighbor on down stream interface 756 If the neighbor is considered to be on a downstream 757 interface for that route, then the neighbor should be 758 registered as a downstream dependent router for that route. 760 If this is the first time the neighbor has indicated 761 downstream dependence for this source and one or more prunes 762 have been sent upstream containing this source network, then 763 Graft messages will need to be sent upstream in the 764 direction of the source network for each group with existing 765 prune state. 767 b. Neighbor not on down stream interface 769 If the receiving router thinks the neighbor is on the 770 upstream interface, then the indication of downstream 771 dependence should be ignored. 773 4. 2 x infinity <= New metric 775 If the metric is greater than or equal to 2 x infinity, the 776 metric is illegal and the route should be ignored. 778 3.4.6. Route Hold-down 780 When a route learned via a particular gateway expires, a router may 781 be able to reach the source network described by the route through an 782 alternate gateway. However, in the presence of complex topologies, 783 often, the alternate gateway may only be echoing back the same route 784 learned via a different path. If this occurs, the route will continue 785 to be propagated long after it is no longer valid. 787 In order to prevent this, it is common in distance vector protocols 788 to continue to advertise a route that has been deleted with a metric 789 of infinity for one or more report intervals. During this time, the 790 route may be learned via a different gateway and the router is 791 permitted to use this new gateway. However, the router MUST NOT 792 advertise this new gateway during the hold-down period. 794 DVMRP begins the hold-down period after 140 seconds (2 x Route Report 795 Interval + 20). After this time, a new gateway may be used but the 796 route must be advertised with an infinity metric for 2 Report 797 Intervals. At this point, the hold-down period is over and the new 798 gateway (if one exists) can start being advertised. In the absence 799 of a new gateway, the route is simply removed. 801 Route hold-down is not effective if only some of the routers 802 implement it. Therefore, it is now a REQUIRED part of the protocol. 804 3.4.7. Graceful Shutdown 806 During a graceful shutdown, an implementation MAY want to inform 807 neighbor routers that it is terminating. Routes that have been 808 advertised with a metric less than infinity should now be advertised 809 with a metric equal to infinity. This will allow neighbor routers to 810 switch more quickly to an alternate path for a source network if one 811 exists. 813 Routes that have been advertised with a metric between infinity and 2 814 x infinity (indicating downstream neighbor dependence) should now be 815 advertised with a metric equal to infinity (canceling the downstream 816 dependence). 818 3.4.8. Route Report Packet Format 820 The format of a sample Route Report Packet is shown in Figure 4 821 below. The packet shown is an example of how the source networks are 822 packed into a Report. The number of octets in each Source Network 823 will vary depending on the mask value. The values below are only an 824 example for clarity and are not intended to represent the format of 825 every Route Report. 827 7 15 23 31 828 +-----------+------------+-------------------------+ 829 | Type | Code | Checksum | 830 | (0x13) | (0x2) | | 831 +-----------+------------+------------+------------+ 832 | Reserved | Minor | Major | 833 | | Version | Version | 834 +-----------+------------+------------+------------+ 835 | Mask1 | Mask1 | Mask1 | Src | 836 | Octet2 | Octet3 | Octet4 | Net11 | 837 +-----------+------------+------------+------------+ 838 | SrcNet11(cont.)... | Metric11 | Src | 839 | | | Net12 | 840 +------------------------+------------+------------+ 841 | SrcNet12(cont.)... | Metric12 | Mask2 | 842 | | | Octet2 | 843 +-----------+------------+------------+------------+ 844 | Mask2 | Mask2 | SrcNet21 | 845 | Octet3 | Octet4 | | 846 +-----------+------------+------------+------------+ 847 | SrcNet21(cont.)... | Metric21 | Mask3 | 848 | | | Octet2 | 849 +-----------+------------+------------+------------+ 850 | Mask3 | Mask3 | ... | 851 | Octet3 | Octet4 | | 852 +-----------+------------+-------------------------+ 854 Figure 4 - Example Route Report Packet Format 856 3.5. Pruning 858 DVMRP is described as a broadcast and prune multicast routing 859 protocol since datagrams are initially sent out all dependent 860 downstream interfaces forming a tree rooted at the source of the 861 data. But as the routers at the leafs of the tree begin to receive 862 unwanted multicast traffic, they send prune messages upstream toward 863 the source. This allows the tree branches to become optimal for a 864 given source network and a given set of receivers. 866 3.5.1. Leaf Networks 867 Detection of leaf networks is very important to the pruning process. 868 Routers at the end of a source specific multicast delivery tree must 869 detect that there are no further downstream routers. This detection 870 mechanism is covered above in section 3.2 titled Probe Messages. If 871 there are no group members present for a particular multicast 872 datagram received, the leaf routers will start the pruning process by 873 removing their downstream interfaces and sending a prune to the 874 upstream router for that source. 876 3.5.2. Source Networks 878 It is important to note that prunes are specific to a group and 879 source network. A prune sent upstream triggered by traffic received 880 from a particular source applies to all sources on that network. It 881 is not currently possible to remove only one or a subset of hosts on 882 a source network for a particular group. All or none of the sources 883 must be removed. 885 Although the Prune message contains the host address of a source, the 886 source network can be determined easly by a best-match lookup using 887 the unicast routing table distributed as a part of DVMRP. 889 3.5.3. Receiving a Prune 891 When a prune is received, the following steps should be taken: 893 1. Determine if a Probe has been received from this router recently. 895 2. If not, discard prune since there is no prior state about this 896 neighbor. 898 3. If so, make sure the neighbor is capable of pruning (based on 899 received Probe message). 901 4. Since Prune messages are fixed length, ensure the prune message 902 contains at least the correct amount of data. 904 5. Extract the source address, group address, and prune time-out 905 values 907 6. If there is no current state information for the (source, group) 908 pair, then ignore the prune. 910 7. Verify that the prune was received from a dependent neighbor for 911 the source network. If not, discard the prune. 913 8. Determine if a prune is currently active from the same dependent 914 neighbor for this (source, group) pair. 916 9. If so, reset the timer to the new time-out value. Otherwise, 917 create state for the new prune and set a timer for the prune 918 lifetime. 920 10. Determine if all dependent downstream routers on the interface 921 from which the prune was received have now sent prunes. 923 11. If so, then determine if there are group members active on the 924 interface. 926 12. If no group members are found, then remove the interface. 928 13. If all downstream interfaces have now been removed, send a prune 929 to the upstream neighbor. 931 3.5.4. Sending a Prune 933 When sending a prune upstream, the following steps should be taken: 935 1. Decide if upstream neighbor is capable of receiving prunes. 937 2. If not, then proceed no further. 939 3. Stop any pending Grafts awaiting acknowledgments. 941 4. Determine the prune lifetime. This value should be the minimum of 942 the prune lifetimes remaining from the downstream neighbors and 943 the default prune lifetime. 945 5. Form and transmit the packet to the upstream neighbor for the 946 source. 948 3.5.5. Retransmitting a Prune 950 By increasing the prune lifetime to ~2 hours, the effect of a lost 951 prune message becomes more apparent. Therefore, an implementation MAY 952 choose to retransmit prunes messages using exponential back-off for 953 the lifetime of the prune if traffic is still arriving on the 954 upstream interface. 956 One way to implement this would be to send a prune, install a 957 negative cache entry for 3 seconds while waiting for the prune to 958 take effect. Then remove the negative cache entry. If traffic 959 continues to arrive, a new forwarding cache request will be 960 generated. The prune can be resent with the remaining prune lifetime 961 and a negative cache entry can be installed for 6 seconds. After 962 this, the negative cache entry is removed. This procedure is repeated 963 while each time doubling the length of time the negative cache entry 964 is installed. 966 3.5.6. Prune Packet Format 968 In addition to the standard IGMP and DVMRP headers, a Prune Packet 969 contains three additional fields: the source host IP address, the 970 destination group IP address, and the Prune Lifetime in seconds. 972 The Prune Lifetime is a derived value calculated as the minimum of 973 the default prune lifetime (2 hours) and the remaining lifetimes of 974 of any downstream prunes received for the same cache entry. A router 975 with no downstream dependent neighbors would use the the default 976 prune lifetime. 978 7 15 23 31 979 +-----------+------------+-------------------------+ 980 | Type | Code | Checksum | 981 | (0x13) | (0x7) | | 982 +-----------+------------+------------+------------+ 983 | Reserved | Minor | Major | 984 +------------------------+------------+------------+ 985 | Source Address | 986 +--------------------------------------------------+ 987 | Group Address | 988 +--------------------------------------------------+ 989 | Prune Lifetime | 990 +--------------------------------------------------+ 992 Figure 5 - Prune Packet Format 994 3.6. Grafting 996 Once a multicast delivery tree has been pruned back, DVMRP Graft 997 messages are necessary to join new receivers onto the multicast tree. 998 Graft messages are sent upstream from the new receiver's first-hop 999 router until a point on the multicast tree is reached. Graft 1000 messages are re-originated between adjacent DVMRP routers and are not 1001 forwarded by DVMRP routers. Therefore, the first-hop router does not 1002 know if the Graft message ever reaches the multicast tree. To remedy 1003 this, each Graft message is acknowledged hop by hop. This ensures 1004 that the Graft message is not lost somewhere along the path between 1005 the receiver's first-hop router and the closest point on the 1006 multicast delivery tree. 1008 One or more Graft messages should be sent under the following 1009 conditions: 1011 1. A new local member joins a group that has been pruned upstream. 1013 2. A new dependent downstream router appears on a pruned branch. 1015 3. A dependent downstream router on a pruned branch restarts (new 1016 Generation ID). 1018 4. A Graft Retransmission Timer expires before a Graft-Ack is 1019 received. 1021 3.6.1. Grafting Each Source Network 1023 It is important to realize that prunes are source specific and are 1024 sent up different trees for each source. Grafts are sent in response 1025 to a new Group Member which is not source specific. Therefore, 1026 separate Graft messages must be sent to the appropriate upstream 1027 routers to counteract each previous source specific prune that was 1028 sent. 1030 3.6.2. Sending a Graft 1032 As mentioned above, a Graft message sent to the upstream DVMRP router 1033 should be acknowledged hop by hop guaranteeing end-to-end delivery. 1034 If a Graft Acknowledgment is not received within the Graft 1035 Retransmission Time-out period, the Graft should be resent to the 1036 upstream router. The initial retransmission period is 5 seconds. A 1037 binary exponential back-off policy is used on subsequent 1038 retransmissions. In order to send a Graft message, the following 1039 steps should be taken: 1041 1. Verify a forwarding cache entry exists for the (source, group) 1042 pair and that a prune exists for the cache entry. 1044 2. Verify that the upstream router is capable of receiving prunes 1045 (and therefore grafts). 1047 3. Add the graft to the retransmission timer list awaiting an 1048 acknowledgment. 1050 4. Formulate and transmit the Graft packet. 1052 3.6.3. Receiving a Graft 1054 The actions taken when a Graft is received depends on the state in 1055 the receiving router for the (source, group) pair in the received 1056 Graft message. If the receiving router has prune state for the 1057 (source, group) pair, then it must acknowledge the received graft and 1058 send a subsequent graft to its upstream router. If the receiving 1059 router has some removed some downstream interfaces but has not sent a 1060 prune upstream, then the receiving interface can simply be added to 1061 the list of downstream interfaces in the forwarding cache. A Graft 1062 Acknowledgment must also be sent back to the source of the Graft 1063 message. If the receiving router has no state at all for the 1064 (source, group) pair, then datagrams arriving for the (source, group) 1065 pair should automatically be flooded when they arrive. A Graft 1066 Acknowledgment must be sent to the source of the Graft message. If a 1067 Graft message is received from an unknown neighbor, it should be 1068 discarded after it is acknowledged. 1070 3.6.4. Graft Packet Format 1072 The format of a Graft packet is show below: 1074 7 15 23 31 1075 +-----------+------------+-------------------------+ 1076 | Type | Code | Checksum | 1077 | (0x13) | (0x8) | | 1078 +-----------+------------+------------+------------+ 1079 | Reserved | Minor | Major | 1080 +------------------------+------------+------------+ 1081 | Source Address | 1082 +--------------------------------------------------+ 1083 | Group Address | 1084 +--------------------------------------------------+ 1086 Figure 6 - Graft Packet Format 1088 3.6.5. Sending a Graft Acknowledgment 1090 A Graft Acknowledgment packet is sent to a downstream neighbor in 1091 response to receiving a Graft message. All Graft messages should be 1092 acknowledged. This is true even if no other action is taken in 1093 response to receiving the Graft to prevent the source from 1094 continually re-transmitting the Graft message. The Graft 1095 Acknowledgment packet is identical to the Graft packet except that 1096 the DVMRP code in the common header is set to Graft Ack. This allows 1097 the receiver of the Graft Ack message to correctly identify which 1098 Graft was acknowledged and stop the appropriate retransmission timer. 1100 3.6.6. Receiving a Graft Acknowledgment 1102 When a Graft Acknowledgment is received, the (source, group) pair in 1103 the packet can be used to determine if a Graft was sent to this 1104 particular upstream router. If no Graft was sent, the Graft Ack can 1105 simply be ignored. If a Graft was sent, and the acknowledgment has 1106 come from the correct upstream router, then it has been successfully 1107 received and the retransmission timer for the Graft can be stopped. 1109 3.6.7. Graft Acknowledgment Packet Format 1111 The format of a Graft Ack packet (which is identical to that of a 1112 Graft packet) is show below: 1114 7 15 23 31 1115 +-----------+------------+-------------------------+ 1116 | Type | Code | Checksum | 1117 | (0x13) | (0x9) | | 1118 +-----------+------------+------------+------------+ 1119 | Reserved | Minor | Major | 1120 +------------------------+------------+------------+ 1121 | Source Address | 1122 +--------------------------------------------------+ 1123 | Group Address | 1124 +--------------------------------------------------+ 1126 Figure 7 - Graft Ack Packet Format 1128 3.7. Interfaces 1130 Interfaces running DVMRP will either be multicast capable physical 1131 interfaces or encapsulated tunnel pseudo-interfaces. Physical 1132 interfaces may either be multi-access networks or point-to-point 1133 networks. Tunnel interfaces are used when there are non-multicast 1134 capable routers between DVMRP neighbors. Protocol messages and 1135 multicast data traffic are sent between tunnel endpoints using IP-IP 1136 encapsulation. The unicast IP addresses of the tunnel endpoints are 1137 used as the source and destination IP addresses in the outer IP 1138 header. The inner IP header remains unchanged from the original 1139 packet. 1141 The maximum packet length of any DVMRP message should be the maximum 1142 packet size required to be forwarded without fragmenting. The use of 1143 Path MTU Discovery [Mogu90] is encouraged to determine this size. In 1144 the absence of Path MTU, the Requirements for Internet Hosts [Brad89] 1145 specifies this number as 576 octets. Be sure to consider the size of 1146 the encapsulated IP header as well when calculating the maximum size 1147 of a DVMRP protocol message. 1149 4. IANA Considerations 1151 The Internet Assigned Numbers Authority (IANA) is the central 1152 coordinator for the assignment of unique parameter values for 1153 Internet protocols. DVMRP uses IGMP [Fen96a] IP protocol messages to 1154 communicate between routers. The IGMP Type field is hexadecimal 0x13. 1156 On IP multicast capable networks, DVMRP uses the All-DVMRP-Routers 1157 local multicast group. This group address is 224.0.0.4. 1159 5. Network Management Considerations 1161 DVMRP provides several methods for network management monitoring and 1162 troubleshooting. Appendix B describes a request/response mechanism to 1163 directly query DVMRP neighbor information. In addition, a Management 1164 Information Base for DVMRP is defined in [Thal96]. A protocol 1165 independent multicast trace-route facility is defined in [Fen96b]. 1167 6. Security Considerations 1169 Security for DVMRP follows the general security architecture provided 1170 for the Internet Protocol [Atk95a]. This framework provides for both 1171 privacy and authentication. It recommends the use of the IP 1172 Authentication Header [Atk95b] to provide trusted neighbor 1173 relationships. Confidentiality is provided by the addition of the IP 1174 Encapsulating Security Payload [Atk95c]. Please refer to these 1175 documents for the general architecture design as well as the specific 1176 implementation details. 1178 7. References 1180 [Atk95a] Atkinson, R., "Security Architecture for the Internet 1181 Protocol", RFC 1825, August 1995. 1183 [Atk95b] Atkinson, R., "IP Authentication Header", RFC 1826, August 1184 1995. 1186 [Atk95c] Atkinson, R., "IP Encapsulating Security Payload (ESP)", 1187 RFC 1827, August 1995. 1189 [Brad89] Braden, R., "Requirements for Internet Hosts -- 1190 Communication Layers", RFC 1122, October 1989. 1192 [Deer89] Deering, S., "Host Extensions for IP Multicasting", RFC 1193 1112, August 1989. 1195 [Deer90] Deering, S., Cheriton, D., "Multicast Routing in Datagram 1196 Internetworks and Extended LANs", ACM Transactions on 1197 Computer Systems, Vol. 8, No. 2, May 1990, pp. 85-110. 1199 [Deer91] Deering, S., "Multicast Routing in a Datagram 1200 Internetwork", PhD thesis, Electric Engineering Dept., 1201 Stanford University, December 1991. 1203 [Fen96a] Fenner, W., "Internet Group Management Protocol, Version 1204 2", Work In Progress, January 1997. 1206 [Fen96b] Fenner, W., Casner, S., "A "traceroute" facility for IP 1207 Multicast", Work In Progress, November 1996. 1209 [Full93] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 1210 Inter-Domain Routing (CIDR): an Address Assignment and 1211 Aggregation Strategy", RFC 1519, September 1993. 1213 [Mogu90] Mogul, J., Deering, S., "Path MTU Discovery", RFC 1191, 1214 November 1990. 1216 [Perk96] Perkins, C., IP Encapsulation within IP, RFC 2003, October 1217 1996. 1219 [Perl92] Perlman, R., Interconnections: Bridges and Routers, 1220 Addison-Wesley, May 1992, pp. 205-211. 1222 [Rekh93] Rekhter, Y., and T. Li, "An Architecture for IP Address 1223 Allocation with CIDR", RFC 1518, September 1993. 1225 [Reyn94] Reynolds, J., Postel, J., "Assigned Numbers", STD 0002, 1226 October 1994. 1228 [Thal96] Thaler, D., "Distance-Vector Multicast Routing Protocol 1229 MIB", Work In Progress, June 1996. 1231 [Wait88] Waitzman, D., Partridge, C., Deering, S., "Distance Vector 1232 Multicast Routing Protocol", RFC 1075, November 1988. 1234 8. Author's Address 1236 Thomas Pusateri 1237 Juniper Networks, Inc. 1238 3260 Jay St. 1239 Santa Clara, CA 95051 1240 Phone: (919) 558-0700 1241 EMail: pusateri@jnx.com 1243 9. Acknowledgments 1245 The author would like to acknowledge the original designers of the 1246 protocol, Steve Deering, Craig Partridge, and David Waitzman. 1247 Version 3 of the protocol would not have been possible without the 1248 original work of Ajit Thyagarajan and ongoing work of Bill Fenner. 1249 Credit also goes to Danny Mitzel for the careful review of this 1250 document and Dave LeRoy and Shuching Shieh for their helpful 1251 comments. 1253 10. Appendix A - Constants & Configurable Parameters 1255 The following table provides a summary of the DVMRP timing 1256 parameters: 1258 Parameter Value (seconds) 1259 ---------------------------------------------------- 1260 Probe Interval 10 1261 Neighbor Time-out Interval 35 1262 Minium Flash Update Interval 5 1263 Route Report Interval 60 1264 Route Replacement Time 140 1265 Route Expiration Time 200 1266 Prune Lifetime variable (< 2 hours) 1267 Prune Retransmission Time 3 with exp. back-off 1268 Graft Retransmission Time 5 with exp. back-off 1269 ---------------------------------------------------- 1271 Table 2 - Parameter Summary 1273 11. Appendix B - Tracing and Troubleshooting support 1275 There are several packet types used to gather DVMRP specific 1276 information. They are generally used for diagnosing problems or 1277 gathering topology information. The first two messages are now 1278 obsoleted and should not be used. The remaining two messages provide 1279 a request/response mechanism to determine the versions and 1280 capabilities of a particular DVMRP router. 1282 Code Packet Type Description 1283 ----------------------------------------------------------- 1284 3 DVMRP Ask Neighbors Obsolete 1285 4 DVMRP Neighbors Obsolete 1286 5 DVMRP Ask Neighbors 2 Request Neighbor List 1287 6 DVMRP Neighbors 2 Respond with Neighbor List 1288 ----------------------------------------------------------- 1290 Table 3 - Debugging Packet Types 1292 11.1. DVMRP Ask Neighbors2 1294 The Ask Neighbors2 packet is a unicast request packet directed at a 1295 DVMRP router. The destination should respond with a unicast 1296 Neighbors2 message back to the sender of the Ask Neighbors2 message. 1298 0 8 16 31 1299 +---------+---------+--------------------+ 1300 | Type | Code | Checksum | 1301 |(0x13) | (0x5) | | 1302 +---------+---------+----------+---------+ 1303 | Reserved | Minor | Major | 1304 | | Version |Version | 1305 +-------------------+----------+---------+ 1307 Figure 8 - Ask Neighbors 2 Packet Format 1309 11.2. DVMRP Neighbors2 1311 The format of a Neighbors2 response packet is shown below. This is 1312 sent as a unicast message back to the sender of an Ask Neighbors2 1313 message. There is a common header at the top followed by the routers 1314 capabilities. One or more sections follow that contain an entry for 1315 each logical interface. The interface parameters are listed along 1316 with a variable list of neighbors learned on each interface. 1318 If the interface is down or disabled, list a single neighbor with an 1319 address of 0.0.0.0 for physical interfaces or the remote tunnel 1320 endpoint address for tunnel pseudo-interfaces. 1322 0 8 16 31 1323 +-----------+--------------+--------------------------+ 1324 | Type | Code | Checksum | 1325 | (0x13) | (0x6) | | 1326 +-----------+--------------+------------+-------------+ 1327 | Reserved | Capabilities | Minor | Major | 1328 | | | Version | Version | 1329 +-----------+--------------+------------+-------------+ 1330 | | 1331 | Local Addr 1 | 1332 +-----------+--------------+------------+-------------+ 1333 | | | | | 1334 | Metric 1 | Threshold 1 | Flags 1 | Nbr Count 1 | 1335 +-----------+--------------+------------+-------------+ 1336 | | 1337 | Nbr 1 | 1338 +-----------------------------------------------------+ 1339 | | 1340 | ... | 1341 +-----------------------------------------------------+ 1342 | | 1343 | Nbr m | 1344 +-----------------------------------------------------+ 1345 | | 1346 | Local Addr N | 1347 +-----------+--------------+------------+-------------+ 1348 | | | | | 1349 | Metric N | Threshold N | Flags N | Nbr Count N | 1350 +-----------+--------------+------------+-------------+ 1351 | | 1352 | Nbr 1 | 1353 +-----------------------------------------------------+ 1354 | | 1355 | ... | 1356 +-----------------------------------------------------+ 1357 | | 1358 | Nbr k | 1359 +-----------------------------------------------------+ 1361 Figure 9 - Neighbors 2 Packet Format 1363 The capabilities of the local router are defined as follows: 1365 Bit Flag Description 1366 --------------------------------------------------- 1368 0 Leaf This is a leaf router 1370 1 Prune This router understands pruning 1372 2 GenID This router sends Generation Id's 1374 3 Mtrace This router handles Mtrace requests 1376 4 Snmp This router supports the DVMRP MIB 1377 --------------------------------------------------- 1379 Table 4 - DVMRP Router Capabilities 1381 The flags associated with a particular interface are: 1383 Bit Flag Description 1384 ---------------------------------------------------------- 1386 0 Tunnel Neighbor reached via tunnel 1388 1 Source Route Tunnel uses IP source routing 1390 2 Reserved No longer used 1392 3 Down Operational status down 1394 4 Disabled Administrative status down 1396 5 Reserved No longer used 1398 6 Leaf No downstream neighbors on interface 1399 ---------------------------------------------------------- 1401 Table 5 - DVMRP Interface flags 1403 12. Appendix C - Version Compatibility 1405 There have been two previous major versions of DVMRP with 1406 implementations still in circulation. If the receipt of a Probe 1407 message reveals a major version of 1 or 2, then it can be assumed 1408 that this neighbor does not support pruning or the use of the 1409 Generation ID in the Probe message. However, since these older 1410 implementations are known to safely ignore the Generation ID and 1411 neighbor information in the Probe packet, it is not necessary to 1412 send specially formatted Probe packets to these neighbors. 1414 There were three minor versions (0, 1, and 2) of major version 3 1415 that did support pruning but did not support the Generation ID or 1416 capability flags. These special cases will have to be accounted 1417 for. 1419 Any other minor versions of major version 3 closely compare to 1420 this specification. 1422 In addition, cisco Systems is known to use their software major 1423 and minor release number as the DVMRP major and minor version 1424 number. These will typically be 10 or 11 for the major version 1425 number. Pruning was introduced in Version 11. 1427 Implementations prior to this specification may not wait to send 1428 route reports until probe messages have been received with the 1429 routers address listed. Reports SHOULD be sent to these neighbors 1430 without first requiring a received probe with the routers address 1431 in it as well as reports from these neighbors SHOULD be accepted. 1432 Although, this allows one-way neighbor relationships to occur, it 1433 does maintain backward compatibility. 1435 Table of Contents 1437 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 1438 1.1. Reverse Path Multicasting . . . . . . . . . . . . . . 2 1439 1.2. IP-IP Tunnels . . . . . . . . . . . . . . . . . . . . 2 1440 1.3. Document Overview . . . . . . . . . . . . . . . . . . 3 1441 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 3 1442 2.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . 3 1443 2.2. Source Location . . . . . . . . . . . . . . . . . . . 4 1444 2.3. Dependent Downstream Routers . . . . . . . . . . . . . 5 1445 2.4. Multi-access Networks . . . . . . . . . . . . . . . . 5 1446 2.5. Building Multicast Trees . . . . . . . . . . . . . . . 6 1447 2.6. Pruning Multicast Trees . . . . . . . . . . . . . . . 7 1448 2.7. Grafting Multicast Trees . . . . . . . . . . . . . . . 7 1449 3. Detailed Protocol Operation . . . . . . . . . . . . . . . . 8 1450 3.1. Protocol Header . . . . . . . . . . . . . . . . . . . 8 1451 3.2. Probe Messages . . . . . . . . . . . . . . . . . . . . 9 1452 3.3. Building Forwarding Cache Entries . . . . . . . . . . 14 1453 3.4. Unicast Route Exchange . . . . . . . . . . . . . . . . 14 1454 3.5. Pruning . . . . . . . . . . . . . . . . . . . . . . . 21 1455 3.6. Grafting . . . . . . . . . . . . . . . . . . . . . . . 25 1456 3.7. Interfaces . . . . . . . . . . . . . . . . . . . . . . 29 1457 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 1458 5. Network Management Considerations . . . . . . . . . . . . . 29 1459 6. Security Considerations . . . . . . . . . . . . . . . . . . 30 1460 7. References . . . . . . . . . . . . . . . . . . . . . . . . 30 1461 8. Author's Address . . . . . . . . . . . . . . . . . . . . . 31 1462 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31 1463 10. Appendix A - Constants & Configurable Parameters . . . . . 32 1464 11. Appendix B - Tracing and Troubleshooting support . . . . . 33 1465 11.1. DVMRP Ask Neighbors2 . . . . . . . . . . . . . . . . 33 1466 11.2. DVMRP Neighbors2 . . . . . . . . . . . . . . . . . . 34 1467 12. Appendix C - Version Compatibility . . . . . . . . . . . . 38