idnits 2.17.1 draft-ietf-rip-ripng-applic-00.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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 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 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.) 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.) -- The document date (August 1996) is 10115 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) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 draft-ietf-rip-ripng-applic-00.txt G. Malkin/Xylogics 3 August 1996 5 RIPng Protocol Applicability Statement 7 Abstract 9 As required by Routing Protocol Criteria (RFC 1264), this report 10 defines the applicability of the RIPng protocol within the Internet. 11 This report is a prerequisite to advancing RIPng on the standards 12 track. 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 30 Rim). 32 1. Protocol Documents 34 The RIPng protocol description is defined in Internet Draft "draft- 35 ietf-rip-ripng-03.txt". 37 2. Introduction 39 This report describes how RIPng may be useful within the new IPv6 40 Internet. In essence, the environments in which RIPng is the IGP of 41 choice is comparable to the environments in which RIP-2 (RFC 1723) is 42 used in the IPv4 Internet. It is important to remember that RIPng is 43 a simple extrapolation of RIP-2; RIPng has nothing conceptually new. 44 Thus, the operational aspects of distance-vector routing protocols, 45 and RIP-2 in particular, within an autonomous system are well 46 understood. 48 It should be noted that RIPng is not intended to be a substitute for 49 OSPFng in large autonomous systems; the restrictions on AS diameter 50 and complexity which applied to RIP-2 also apply to RIPng. Rather, 51 RIPng allows the smaller, simpler, distance-vector protocol to be 52 used in environments which require authentication or the use of 53 variable length subnet masks, but are not of a size or complexity 54 which require the use of the larger, more complex, link-state 55 protocol. 57 The remainder of this report describes how each of the features of 58 RIPng is useful within IPv6. 60 3. Applicability 62 A goal in developing RIPng was to make the minimum necessary change 63 to RIP-2 to produce RIPng. In essence, the IPv4 address was expanded 64 into an IPv6 address, the IPv4 subnet mask was replaced with an IPv6 65 prefix length, the next-hop field was eliminated but the 66 functionality has been preserved, and authentication was removed. 67 The route tag field has been preserved. The maximum diameter of the 68 network (the maximum metric value) is 15; 16 still means infinity 69 (unreachable). 71 The basic RIP header is unchanged. However, the size of a routing 72 packet is no longer arbitrarily limited. Because routing updates are 73 never forwarded, the routing packet size is now determined by the 74 physical media and the sizes of the headers which precede the routing 75 data (i.e., media MTU minus the combined header lengths). The number 76 routes which may be included in a routing update is the routing data 77 length divided by the size of a routing entry. 79 3.1 Prefix 81 The address field of a routing entry is 128 bits in length, expanded 82 from the 32 bits available in RIP-2. This allows the RIP entry to 83 carry an IPv6 prefix. 85 3.2 Prefix Length 87 The 32-bit RIP-2 subnet mask field is replaced by an 8-bit prefix 88 length field. It allows the specification of the number of bits in 89 the prefix which form the actual prefix. 91 3.3 Next Hop 93 The ability to specify the next hop, rather than simply allowing the 94 recipient of the update to set the next hop to the sender of the 95 update, allows for the elimination of unnecessary hops through 96 routers which are running multiple routing protocols. Consider 97 following example topology: 99 ----- ----- ----- ----- 100 |IR1| |IR2| |XR1| |XR2| 101 --+-- --+-- --+-- --+-- 102 | | | | 103 --+-------+-------------+-------+-- 104 |--------RIPng--------| 106 The Internal Routers (IR1 and IR2) are only running RIPng. The 107 External Routers (XR1 and XR2) are both running BGP, for example; 108 however, only XR1 is running BGP and RIPng. Since XR2 is not running 109 RIPng, the IRs will not know of its existance and will never use it 110 as a next hop, even if it is a better next hop than XR1. Of course, 111 XR1 knows this and can indicate, via the Next Hop mechanism, that XR2 112 is the better next hop for some routes. 114 3.4 Authentication 116 Authentication, which was added to RIP-2 because RIP-1 did not have 117 it, has been dropped from RIPng. This is safe to do because IPv6, 118 which carries the RIPng packets, has build in security which IPv4 did 119 not have. 121 3.5 Packet Length 123 By allowing RIPng routing update packets to be as big as possible, 124 the number of packets which must be sent for a complete update is 125 greatly reduced. This in no way affects the operation of the 126 distance-vector protocol; it is merely a performance enhancement. 128 3.6 Diameter and Complexity 130 The limit of 15 cost-1 hops is a function of the distance-vector 131 protocol, which depends on counting to infinity to resolve some 132 routing loops. If infinity is too high, the time it would take to 133 resolve, not to mention the number of routing updates which would be 134 sent, would be prohibitive. If the infinity is too small, the 135 protocol becomes useless in a reasonably sized network. The choice 136 of 16 for infinity was made in the earliest of RIP implementations 137 and experience has shown it to be a good compromise value. 139 RIPng will efficiently support networks of moderate complexity. That 140 is, topologies without too many multi-hop loops. RIPng also 141 effeciently supports topologies which change frequently because 142 routing table changes are made incrementally and do not require the 143 computation which link-state protocols require to rebuild their maps. 145 4. Conclusion 147 Because the basic protocol is unchanged, RIPng is as correct a 148 routing protocol as RIP-2. RIPng serves the same niche for IPv6 as 149 RIP-2 does for IPv4. 151 5. Security 153 RIPng security is discussed in section 3.4. 155 Author's Address 157 Gary Scott Malkin 158 Xylogics/Bay Networks 159 53 Third Avenue 160 Burlington, MA 01803 162 Phone: (617) 238-6237 163 EMail: gmalkin@xylogics.com