idnits 2.17.1 draft-meyer-rip-analysis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 73 has weird spacing: '...ion and datab...' -- 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 (Dec 1993) is 11089 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1264 (ref. '1') (Obsoleted by RFC 4794) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. '3') ** Obsolete normative reference: RFC 1388 (ref. '4') (Obsoleted by RFC 1723) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G.M. Meyer 3 Internet Draft Spider Systems 4 Expires Jun 21, 1994 Dec 1993 6 Protocol Analysis for Extensions to RIP to Support Demand Circuits 7 draft-meyer-rip-analysis-02.txt 9 Status of this Memo 11 This memo is being distributed to members of the Internet community 12 in order to solicit their reactions to the proposals contained in it. 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. Internet Drafts are draft 18 documents valid for a maximum of six months. Internet Drafts may be 19 updated, replaced, or obsoleted by other documents at any time. It 20 is not appropriate to use Internet Drafts as reference material or to 21 cite them other than as a ``working draft'' or ``work in progress.'' 22 Please check the 1id-abstracts.txt listing contained in the 23 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 24 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 25 current status of any Internet Draft. 27 Distribution of this memo is unlimited. 29 Abstract 31 As required by Routing Protocol Criteria [1], this report documents 32 the key features of Routing over Demand Circuits on Wide Area 33 Networks - RIP [2] and the current implementation experience. 35 Acknowledgements 37 I would like to thank colleagues at Spider, in particular Richard 38 Edmonstone and Alan Turland who developed Spider's IP RIP and IPX RIP 39 and SAP implementations. 41 1. Protocol Documents 43 "Extensions to RIP to Support Demand Circuits" [2] suggests an 44 enhancement to the "Routing Internet Protocol" (RIP) [3] and "RIP-2" 45 [4] to allow them to run more cost-effectively on Wide Area Networks 46 (WANs). Network management extensions for Demand RIP are described 47 in RIP Version 2 MIB Extensions [5]. 49 2. Applicability 51 Demand RIP requires that there is an underlying mechanism for 52 determining unreachability in a finite predictable period. 54 The demand extensions to RIP are particularly appropriate for WANs 55 where the cost - either financial or packet overhead - would make 56 periodic transmission of routing (or service advertising) updates 57 unacceptable: 59 o Connection oriented Public Data Networks - for example X.25 packet 60 switched networks or ISDN. 62 o Point-to-point links supporting PPP link quality monitoring or 63 echo request to determine link failure. 65 A demand RIP implementation runs standard RIP on Local Area Networks 66 (LANs) allowing them to interoperate transparently with implementa- 67 tions adhering to the original specifications. 69 3. Key Features 71 The proposal shares the same basic algorithms as RIP or RIP-2 when 72 running on LANs or fixed point-to-point links; Packet formats, broad- 73 cast frequency, triggered update operation and database timeouts are 74 all unmodified. 76 The new features operate on WANs which use switched circuits on 77 demand to achieve intermittent connectivity. Instead of using 78 periodic 'broadcasts', information is only sent as triggered updates. 79 The proposal makes use of features of the underlying connection 80 oriented service to provide feedback on connectivity. 82 3.1 Triggered Updates 84 Updates are only sent on the WAN when an event changes the routing 85 database. Each update is retransmitted until acknowledged. Informa- 86 tion received in an update is not timed out. 88 The packet format of a RIP response is modified (with a different 89 unique command field) to include sequence and fragment number infor- 90 mation. An acknowledgement packet is also defined. 92 3.2 Circuit Manager 94 The circuit manager running below the IP network layer is responsible 95 for establishing a circuit to the next hop router whenever there is 96 data (or a routing update) to transfer. After a period of inactivity 97 the circuit will be closed by the circuit manager. 99 If the circuit manager fails to make a connection a circuit down 100 indication is sent to the routing application. The circuit manager 101 will then attempt at (increasing) intervals to establish a connec- 102 tion. When successful a circuit up indication is sent to the rout- 103 ing application. 105 3.3 Presumption of Reachability 107 In a stable network there is no requirement to propagate routing 108 information on a circuit, so if no routing information is (being) 109 received on a circuit it is assumed that: 111 o The most recently received information is accurate. 113 o The intervening path is operational (although there may be no current 114 connection). 116 If the circuit manager determines that the intervening path is NOT 117 operational routing information previously received on that circuit 118 is timed out. It is worth stressing that it can be ANY routed 119 datagram which triggers the event. 121 When the circuit manager re-establishes a connection, the application 122 exchanges full routing information with its peer. 124 3.4 Routing Information Flow Control 126 If the circuit manager reports a circuit as down, the routing appli- 127 cation is flow controlled from sending further information on the 128 circuit. 130 To prevent transmit queue overflow and also to avoid 'predictable' 131 circuit down messages, the routing application can also optionally 132 limit the rate of sending routing messages to an interface. 134 4. Implementations 136 At this stage there is only believed to be one completed implementa- 137 tion. 139 The Spider Systems' implementation supports all the features outlined 140 for IP RIP-1, IPX RIP and IPX SAP. RIP-2 is not currently supported. 141 It has been tested against itself on X.25 and ISDN WANs. It has also 142 been tested in operation with various router and host RIP-1, IPX RIP 143 and IPX SAP implementations on Ethernet LANs. 145 Two other Novell-only implementations are known to be under develop- 146 ment. 148 5. Rrestrictions 150 Demand RIP relies on the ability to place a call in either direction. 151 Some dialup services - for example DTR dialing - allow calls to be 152 made in one direction only. 154 Demand RIP can not operate with third-party advertisement of routes 155 on the WAN. The next hop IP address in RIP-2 should always be 156 0.0.0.0 for any routes advertised on the WAN. 158 6. Security Considerations 160 Security is provided through authentication of the logical and physi- 161 cal address of the sender of the routing update. Incoming call 162 requests are matched by the circuit manager against a list of physi- 163 cal addresses (used to make outgoing calls). The routing application 164 makes a further check against the logical address of an incoming 165 update. 167 Additional security can be provided by RIP-2 authentication [2] where 168 appropriate. 170 References 172 [1] Hinden, R., "Internet Engineering Task Force Internet Routing 173 Protocol Standardization Criteria", RFC 1264, Bolt Beranek and 174 Newman, Inc, October 1991. 176 [2] Meyer. G.M., "Extensions to RIP to Support Demand Circuits", 177 Internet Draft "draft-meyer-demandrouting-03.txt", Spider Sys- 178 tems, Nov 1993. 180 [3] Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers 181 University, June 1988. 183 [4] Malkin. G., "RIP Version 2 - Carrying Additional Information", 184 RFC 1388 Xylogics, 1992. 186 [5] Malkin. G.S. and Baker. F., "RIP Version 2 MIB Extensions", 187 Internet Draft, Xylogics and ACC, 1993. 189 Author's Address: 191 Gerry Meyer 192 Spider Systems 193 Stanwell Street 194 Edinburgh EH6 5NG 195 Scotland, UK 197 Phone: (UK) 31 554 9424 198 Fax: (UK) 31 554 0649 199 Email: gerry@spider.co.uk