idnits 2.17.1 draft-ietf-iesg-cidr-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-23) 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 226 lines 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 20 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- 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) ** Downref: Normative reference to an Informational RFC: RFC 1380 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1338 (ref. '3') (Obsoleted by RFC 1519) ** Obsolete normative reference: RFC 1366 (ref. '4') (Obsoleted by RFC 1466) ** Obsolete normative reference: RFC 1367 (ref. '5') (Obsoleted by RFC 1467) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Historic RFC: RFC 1267 (ref. '8') ** Downref: Normative reference to an Unknown state RFC: RFC 827 (ref. '9') ** Obsolete normative reference: RFC 1247 (ref. '10') (Obsoleted by RFC 1583) ** Obsolete normative reference: RFC 1388 (ref. '12') (Obsoleted by RFC 1723) ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. '13') -- Possible downref: Non-RFC (?) normative reference: ref. '16' Summary: 20 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Internet Engineering Steering Group 2 Applicability Statement for the Implementation of 3 Classless Inter-Domain Routing (CIDR) 5 Abstract 6 -------- 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 "working draft" or "work in progress." 21 Please check the 1id-abstracts.txt listing contained in the 22 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 23 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 24 current status of any Internet Draft. 26 This memo is an draft IESG standards track Applicability Statement for 27 the Internet community, and requests discussion and suggestions for 28 improvements. Please refer to the current edition of the "Official 29 Internet Protocol Standards" for the standardization state and status 30 of this specification. Distribution of this memo is unlimited. 32 1 Introduction 34 As the Internet has evolved and grown in recent years, it has become 35 clear that it will soon face several serious scaling problems. These 36 include: 38 - Exhaustion of the class-B network address space. One 39 fundamental cause of this problem is the lack of a network 40 class of a size that is appropriate for a mid-sized 41 organization. Class-C, with a maximum of 254 host addresses, is 42 too small, while class-B, which allows up to 65534 addresses, 43 is too large to be densely populated. The result is inefficient 44 utilization of class-B network numbers. 46 - Routing information overload. The size and rate of growth of the 47 routing tables in Internet routers is beyond the ability of current 48 software (and people) to effectively manage. 50 - Eventual exhaustion of IP network numbers. 52 It has become clear that the first two of these problems are likely 53 to become critical in the near term. Classless 54 Inter-Domain Routing (CIDR) attempts to deal with these problems by 55 defining a mechanism to slow the growth of routing tables and reduce 56 the need to allocate new IP network numbers. It does not attempt to 57 solve the third problem, which is of a more long-term nature, but 58 instead endeavors to ease enough of the short to mid-term 59 difficulties to allow the Internet to continue to function 60 efficiently while progress is made on a longer-term solution. 62 The IESG, after a thorough discussion in the IETF, in June 1992 63 selected CIDR as the solution for the short term routing table 64 explosion problem [1]. 66 2 Components of the Architecture 68 The CIDR architecture is described in the following documents: 70 - "An Architecture for IP Address Allocation with CIDR" [2] 72 - "Classless Inter-Domain Routing (CIDR): An Address Assignment 73 and Aggregation Strategy" [3] 75 The first of these documents presents the overall architecture of CIDR; 76 the second describes the specific address allocation scheme to be used. 78 In addition to these two documents, "Guidelines for Management of IP 79 Address Space" [4] provides specific recommendations for assigning IP 80 addresses that are consistent with [2] and [3], and "Schedule for Address 81 Space Management Guidelines" [5] describes the timetable for deploying 82 [4] in the Internet. Both [4] and [5] should be viewed as supporting, 83 rather than defining, documents. 85 In addition to the documents mentioned above, CIDR requires that 86 inter-domain routing protocols be capable of handling reachability 87 information that is expressed solely in terms of IP address prefixes. 88 While several inter-domain routing protocols are capable of 89 supporting such functionality, this Applicability Statement does not 90 mandate the use of a particular one. The inter-domain protocols which 91 meets this requirement is: 93 Border Gateway Protocol version 4 [6] 94 Inter-Domain Routing Protocol for IP [7] 96 Inter-Domain routing protocols which do not meet these requirements 97 are: 99 Border Gateway Protocol version 3 [8] 100 Exterior Gateway Protocol [9] 102 While CIDR does not require intra-domain routing protocols to also be 103 CIDR capable, it highly recommends that intra-domain routing protocols 105 Although CIDR does not require that intra-domain routing protocols, as 106 well as inter-domain routing protocols, be capable of supporting CIDR, 107 the benefits of implementing CIDR will be greater if this is the case. 108 If this is not done, then the CIDR route aggregation will need to be 109 undone inside of a routing domain. The CIDR capable intra-domain 110 routing protocols are: 112 Open Shortest Path Routing Protocol [10] 113 Dual-ISIS [11] 114 RIP Version 2 [12] 116 The Intra-Domain routing protocol which is not CIDR capable is: 118 RIP Version 1 [13] 120 3 Applicability of CIDR 122 The CIDR architecture is applicable to any group of connected domains 123 that supports IP version 4 [14] [15] [16]. CIDR does not require all 124 of the domains in the Internet to be converted to use CIDR. On the 125 contrary, it assumes that some of the existing domains in the Internet 126 will never be able to convert. Despite this, CIDR will still provide 127 connectivity to such places, although the optimality of routes to 128 these places may be impacted. 130 This Applicability Statement requires Internet domains providing 131 backbone and/or transit service to fully implement CIDR in order to 132 ensure that the growth of the resources required by routers to provide 133 Internet-wide connectivity will be significantly slower than the 134 growth of the number of assigned networks. 136 This Applicability Statement strongly recommends that all 137 non-backbone/transit Internet domains also implement CIDR because it 138 will reduce the amount of routing information inside of these domains. 140 Individual domains are free to choose whatever inter-domain and 141 intra-domain routing architectures best meet their requirements. 142 Specifically, this Applicability Statement does not prevent a domain 143 or a group of domains from using addressing schemes which do not 144 conform to CIDR. Subject to the available resources in routers, CIDR 145 should be able to co-exist with other addressing schemes without 146 adversely impacting overall connectivity. 148 3. SECURITY CONSIDERATIONS 150 Security issues are not discussed in this memo. 152 4. CONTACT INFORMATION 154 Robert M. Hinden 155 Sun Microsystems 156 2550 Garcia Ave, MS MTV5-44 157 Mt. View, CA 94043 159 Phone: (415) 336-2082 160 Fax: (415) 336-6015 162 Email: hinden@eng.sun.com 164 5. REFERENCES 166 [1] Gross, P., Almquist, P., "IESG Deliberations on Routing and 167 Addressing", RFC1380, November 1992 169 [2] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation 170 with CIDR" (currently an internet-draft) 172 [3] Fuller, V., Li, T., Yu, J., and Varadhan, K., "Classless Inter- 173 Domain Routing (CIDR): An Address Assignment and Aggregation 174 Strategy" (revision of RFC 1338) 176 [4] Gerich, E., "Guidelines for Management of IP Address Space", 177 RFC1366, October 1992 179 [5] Topolcic, C., "Schedule for address space management guidelines", 180 RFC 1367, October 1992 (the IESG has expressed an interest in 181 seeing this schedule revised to reflect the entire Internet; it is 182 currently US-centric) 184 [6] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", 185 IETF Working Paper. 187 [7] Hares, S., "IDRP for IP", Internet Draft, 188 190 [8] Lougheed, K., Rekhter, Y., "A Border Gateway Protocol 3 191 (BGP-3)", RFC 1267, October 1991. 193 [9] Rosen, E.C., "Exterior Gateway Protocol EGP", RFC 827, October 194 1992. 196 [10] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 197 1991. 199 [11] Callon, R. "Use of OSI IS-IS for Routing in TCP/IP and Dual 200 Environments", RFC1195, December 1990. 202 [12] Malkin, G. "RIP Version 2 Carrying Additional Information", 203 RFC 1388, January 1993. 205 [13] Hedrick, C. "Routing Information Protocol", RFC 1058, June 206 1988. 208 [14] Postel, J.B. "Internet Protocol", RFC 791, September 1981. 210 [15] Braden, R., Editor, "Requirements for Internet Hosts -- Communication 211 Layers", IETF, STD 3, RFC 1122, October 1989. 213 [16] Almquist, P., Editor, "Requirements for IP Routers", Work in 214 Preparation, IETF.