idnits 2.17.1 draft-ietf-idmr-dvmrp-v1-as-00.txt: ** The Abstract section seems to be numbered 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-28) 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. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 42 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC-1075]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Deering' ** Downref: Normative reference to an Experimental RFC: RFC 1075 -- Possible downref: Non-RFC (?) normative reference: ref. 'Pusateri' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Coltun 3 draft-ietf-idmr-dvmrp-v1-as-00 FORE Systems 4 S. Deering 5 Cisco 6 T. Pusateri 7 Juniper Networks 8 R. Shekhar 9 FORE Systems 10 Expires: January 1999 12 DVMRPv1 Applicability Statement for Historic Status 14 Status of this Memo 16 This document is an Internet Draft. Internet Drafts are working docu- 17 ments of the Internet Engineering Task Force (IETF), its Areas, and 18 its Working Groups. Note that other groups may also distribute working 19 documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six months. 22 Internet Drafts may be updated, replaced, or obsoleted by other docu- 23 ments at any time. It is not appropriate to use Internet Drafts as 24 reference material or to cite them other than as a "working draft" or 25 "work in progress." 27 To view the entire list of current Internet-Drafts, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 30 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 31 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 33 Distribution of this memo is unlimited. 35 Table Of Contents 37 1.0 Abstract ................................................. 2 39 2.0 Introduction ............................................. 2 41 3.0 DVMRPv1 Restrictions ..................................... 3 43 3.2 Network Advertisements ................................... 3 45 3.3 Tunnel Support ........................................... 3 47 4.0 Conclusion ............................................... 3 49 5.0 Security Considerations .................................. 4 51 6.0 Authors' Addresses ....................................... 4 53 7.0 References ............................................... 4 55 1.0 Abstract 57 DVMRP version 1 (DVMRPv1) [RFC-1075] has been declared a historic 58 document. This applicability statement provides the supporting 59 motivation for that declaration. 61 2.0 Introduction 63 DVMRP is an Internet multicast routing protocol that provides an effi- 64 cient mechanism for datagram delivery to a group of hosts across an 65 internetwork. It is a distributed protocol that dynamically generates 66 IP Multicast delivery trees using a technique called Reverse Path Mul- 67 ticasting (RPM) [Deering]. 69 While current versions of DVMRP are widely used throughout the Inter- 70 net, DVMRPv1 as defined in RFC-1075, is not applicable for use. RFC- 71 1075 describes a very early version of DVMRP which was never fully 72 implemented. A partial implementation was deployed on three Unix boxes 73 for a few months in 1988. Experience with that early implementation 74 led to a complete, non-backwards-compatible redesign; it is the des- 75 cendants of that redesign that are widely implemented and widely used 76 in the MBone and elsewhere. 78 3.0 DVMRPv1 Restrictions 80 DVMRPv1 has a number of restrictions and behaviors which limit its 81 usability in the global Internet. 83 3.1 Protocol Reliability Mechanisms 85 DVMRPv1 had no "keep-alive" mechanism between neighboring DVRMP 86 routers. It was therefore not possible to detect that a router was 87 restarted. A restarted router would introduce inconsistency in the 88 state of previously sent non-membership reports. Until the upstream 89 and downstream dependencies were updated the network would not have 90 consistent information. This would result in slow network convergence. 92 DVMRPv1 did not include acknowledgements for non-membership cancella- 93 tions (i.e., grafts). Consequently, there was no way of knowing 94 whether a graft was lost or the graft was successfully received but 95 the source has stopped transmitting the data. The effects of this was 96 also to slow down network convergence. 98 3.2 Network Advertisements 100 In DVMRPv1, non-membership reports didn't contain source networks, 101 they only contained groups. This resulted in less optimal multicast 102 forwarding trees and multicast data being distributed further down the 103 forwarding tree than necessary. 105 In DVMRPv1, route masks were too restrictive. As a result it was not 106 possible to include the default route (0/0) or a host network mask 107 (/32) in route updates. Additionally, routes with subnet masks were 108 not allowed to be advertised outside of the classful network (i.e., no 109 CIDR support). 111 3.3 Tunnel Support 113 In DVMRPv1 tunnels were supported using the IP loose source route 114 option; protocol messages were sent un-encapsulated directly to the 115 tunnel endpoint. While this was the more direct approach to tunnels, 116 it resulted in a significant performance penalty (in addition to delay 117 and jitter) imposed by most routers on packets that carry IP options. 119 4.0 Conclusion 121 The recommendation of this Applicability Statement is that networks 122 that desire to use DVMRP in a network environment should use the 123 current version of DVMRP (DVMRPv3) as defined in [Pusateri]. 125 5.0 Security Considerations 127 DVMRPv1 includes no security functions. 129 Security for DVMRPv3 follows the general security architecture pro- 130 vided for the Internet Protocol. This framework provides for both 131 privacy and authentication. It recommends the use of the IP Authenti- 132 cation Header to provide trusted neighbor relationships. Confidential- 133 ity is provided by the addition of the IP Encapsulating Security Pay- 134 load. 136 6.0 Authors' Addresses 138 Rob Coltun 139 FORE Systems 140 Phone: (703) 245-4543 141 EMail: rcoltun@fore.com 143 Stephen E. Deering 144 Cisco Systems, Inc. 145 170 West Tasman Drive 146 San Jose, CA 95134-1706 147 EMail: deering@cisco.com 148 Phone: (408) 527-8213 150 Tom Pusateri 151 Juniper Networks, Inc. 152 385 Ravendale Dr. 153 Mountain View, CA 94043 154 Phone: (919) 558-0700 155 EMail: pusateri@juniper.net 157 Ravi Shekhar 158 FORE Systems 159 Phone: (703) 245-4534 160 EMail: rshekhar@fore.com 162 7.0 References 164 [Deering] Deering, S., Cheriton, D., "Multicast Routing in Datagram 165 Internetworks and Extended LANs", ACM Transactions on 166 Computer Systems, Vol. 8, No. 2, May 1990, pp. 85-110. 168 [RFC-1075] Waitzman, D., Partridge, C., Deering, S., "Distance Vector 169 Multicast Routing Protocol", RFC 1075, November 1988. 171 [Pusateri] Pusateri, T. "Distance Vector Multicast Routing Protocol", 172 Work in Progress, May 1998.