idnits 2.17.1 draft-manning-classa-exp-01.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-18) 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 page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 263 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 an Authors' Addresses Section. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 150 instances of lines with control characters in the document. 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 (November 1995) is 10382 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 227 looks like a reference -- Missing reference section? '2' on line 228 looks like a reference -- Missing reference section? '3' on line 230 looks like a reference -- Missing reference section? '4' on line 233 looks like a reference -- Missing reference section? '5' on line 235 looks like a reference -- Missing reference section? '6' on line 236 looks like a reference -- Missing reference section? '7' on line 238 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group net39-testgroup 2 INTERNET-DRAFT bill manning - editor 3 Category: Informational November 1995 4 Expires in six months 6 Class A Subnet Experiment 7 Results and Recommendations 8 10 Status of this Memo 12 This documents the experience the Internet community with the 13 Experimental Protocol defined in RFC 1797. This does not specify 14 an Internet standard of any kind. Continued discussion is requested. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are 18 working documents of the Internet Engineering Task Force 19 (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months. Internet-Drafts may be updated, replaced, or obsoleted 25 by other documents at any time. It is not appropriate to use 26 Internet-Drafts as reference material or to cite them other 27 than as a ``working draft'' or ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check 30 the 1id-abstracts.txt listing contained in the Internet-Drafts 31 Shadow Directories on ds.internic.net, nic.nordu.net, 32 ftp.nisc.sri.com, or munnari.oz.au. 34 Discussion/Purpose 36 This memo documents some experiences with the RFC 1797[1] subnet A 37 experiment and provides a number of recommendations on future 38 direction for both the Internet Registries and the Operations 39 community. 41 Not all proposed experiments in RFC 1797 were done. Only the "case 42 one" type delegations were made. Additional experimentation was done 43 within the DNS service, by supporting a root nameserver and the 44 primary for the domain from within the subnetted address space. 45 In addition, testing was done on classless delegation[2]. 47 Internet Services offered over the RFC 1797 experiment were: 49 Finger 50 HTTP 51 Telnet 52 FTP server/client 53 Gopher 54 kerberos 55 lpr (and its ilk) 56 X 57 DNS 59 F.Root-Servers.Net, a root name server had an interface defined 60 as part of the RFC 1797 experiment. Attached is a report 61 fragment on it's performance: 63 "My root server has processed 400,000,000 queries in the last 38 days, 64 and well over half of them were to the temporary 39.13.229.241 address 65 (note that I retained the old 192.5.5.241 address since I knew a 66 lot of folks would not update their root.cache files and I didn't 67 want to create a black hole.)" - Paul Vixie 69 Initial predictions[3] seemed to indicate that the safest path for 70 an ISP that participates in such a routing system is to have -all- 71 of the ISP clients be either: 73 a) singly connected to one upstream ISP 74 OR 75 b) running a classless interior routing protocol 77 It is also noted that a network with default route may not notice 78 it has potential routing problems until it starts using subnets of 79 traditional A's internally. 81 Problems & Solutions 82 Operations 84 There were initial problems in at least one RIPE181[4] implementation. 85 It is clear that operators need to register in the Internet 86 Routing Registry (IRR) all active aggregates and delegations 87 for any given prefix. Additionally, there need to be methods 88 for determining who is authoritative for announcing any given prefix. 90 It is expected that problems identified within the confines of this 91 experiment are applicable to some RFC 1597 prefixes or any "natural" 92 class "A" space. 94 Use of traceroute (LSRR) was critical for network troubleshooting 95 during this experiment. In current cisco IOS, coding the 96 following statement will disable LSRR and therefore inhibit 97 cross-provider troubleshooting: 99 no ip source-route 101 We recommend that this statement -NOT- be placed in active ISP 102 cisco configurations. 104 In general, there are serious weaknesses in the Inter-Provider 105 cooperation model and resolution of these problems is outside the 106 scope of this document. Perhaps the IEPG or any/all of the national 107 or continental operations bodies[5] will take this as an action 108 item for the continued health and viability of the Internet. 110 Routing 112 A classic cisco configuration that has the following statements 114 ip route 39.1.28.0 255.255.255.0 115 router bgp 64000 116 redistribute static 118 will, by default, promote any classful subnet route to a full 119 classful route (supernet routes will be left alone). This 120 behaviour can be changed in at least the following two ways: 122 1: 123 ip route 39.1.28.0 255.255.255.0 124 router bgp 64000 125 no auto-summary 126 redistribute static 128 2: 129 ip route 39.1.28.0 255.255.255.0 130 router bgp 64000 131 network 39.1.28.0 mask 255.255.255.0 132 redistribute static route-map static-bgp 133 .... 134 access-list 98 deny 39.1.28.0 0.255.255.255 135 access-list 98 permit any 136 .... 137 route-map static-bgp 138 match ip address 98 140 Users of cisco gear currently need to code the following 141 two statements: 143 ip classless 144 ip subnet-zero 146 The implication of the first directive is that it eliminates 147 the idea that if you know how to talk to a subnet of a network, 148 you know how to talk to ALL of the network. 150 The second is needed since it is no longer clear where the 151 all-ones or all-zeros networks are[6]. 153 Other infrastructure gear exhibited similar or worse behaviour. 154 Equipment that depends on use of a classful routing protocol, 155 such a RIPv1 are prone to misconfiguration. Tested examples 156 are current Ascend and Livingston gear, which continue to 157 use RIPv1 as the default/only routing protocol. RIPv1 use 158 will create an aggregate announcement. 160 This pernicious use of this classful IGP was shown to impact 161 otherwise capable systems. When attempting to communicate 162 between an Ascend and a cisco the promotion problem identified 163 above, was manifest. The problem turned out to be that a classful 164 IGP (RIPv1) was being used between the Ascends and ciscos. 165 The Ascend was told to announce 39.1.28/24, but since RIPv1 can't 166 do this, the Ascend instead sent 39/8. We note that RIPv1, as 167 with all classful IGPs should be considered historic. 169 This validates the predictions discussed in [3]. 171 Cisco Specific Examples 173 There are actually three ways to solve the unintended aggregation 174 problem, as described with current cisco IOS. Which of them 175 applies will depend on what software version is in the router. 176 Workarounds can be implemented for ancient (e.g. 8.X) version software. 178 o Preferred solution: turn on "ip classless" in the 179 routers and use a default route inside the AS. 180 The "ip classless" command prevents the existence of 181 a single "subnet" route from blocking access via the 182 default route to other subnets of the same old-style network. 183 Default only works with single-homed ISPs. 185 o Workaround for 9.1 or later software where the 186 "ip classless" command is not available: install a 187 "default network route" like this: 188 "ip route 39.0.0.0 255.0.0.0 " along the axis 189 the default route would normally take. It appears 190 an ISP can utilize the "recursive route lookups" so 191 the "next-hop" may not actually need to be a directly 192 connected neighbour -- the internal router can e.g. 193 point to a loopback interface on the border router. 194 This can become "really uncomfortably messy" and it may 195 be necessary to use a distribute-list to prevent 196 the announcement of the shorter mask. 198 o Workaround for 9.0 or older software: create a 199 "default subnet route": "ip route 39.x.y.0 " 200 combined with "ip default-network 39.x.y.0", otherwise 201 as the 9.1 fix. 203 Both of the latter solutions rely on static routes, and in the 204 long run these will be impossible to maintain. In some 205 topologies the use of static routes can be a problem (e.g. if there 206 is more than one possible exit point from the AS to choose 207 from). 209 Recommendations: 211 The RFC 1797 experiment appears to have been a success. We believe 212 it safe to start carving up "Class A" space, if the spaces are 213 delegated according to normal IR conventions[7] and recommend 214 the IANA consider this for future address delegations. 216 Credits: 218 Thanks to all the RFC 1797 participants. Particular thanks to 219 Paul Vixie, Geert Jan de Groot, and the Staff of the IETF33 Terminal 220 room. Other thanks to ACES, MCI, Alternet, IIJ, UUNET-Canada, 221 Nothwestnet, BBN-Planet, cisco systems, RIPE, ESnet, Xlink, 222 SURFnet, STUPI, Connect-AU, INBEnet, SUNET, EUnet, InterPath, 223 VIX.COM, MindSpring. Especial thanks to Suzanne for cleanup. 225 References: 227 [1] IANA, "Class A Subnet Experiment", RFC 1797, ISI, April 1995 228 [2] H. Eidnes, G. J. de Groot, "Classless in-addr.arpa delegation", 229 Work in Progress, SINTEF RUNIT, RIPE NCC, May 1995 230 [3] G. Huston, "Observations on the use of Components of the 231 Class A Address Space within the Internet", Work in Progress, 232 AARnet, May 1995 233 [4] T. Bates, et.al, "Representation of IP Routing Policies 234 in a Routing Registry", RFC 1786, MCI, March 1995 235 [5] http://info.ra.net/div7/ra/Ops.html, November 1995 236 [6] F. Baker, Editor, "Requirements for IP Version 4 Routers", RFC 1812, 237 cisco systems, June 1995 238 [7] K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, "INTERNET 239 REGISTRY GUIDELINES", Work in Progress, InterNIC, APNIC, RIPE, 240 November 1995 242 Security Considerations: 244 Security was not considered in this experiment. 246 Editor Address: 248 Bill Manning 249 Information Sciences Institute 250 University of Southern California 251 4676 Admiralty Way 252 Marina del Rey, CA 90292-6695 253 USA 254 Phone: +1 310-822-1511 x387 255 Fax: +1 310-823-6714 256 EMail: bmanning@isi.edu 258 --bill