Needs serious polish... Comments? -------------------------------------------- Network Working Group net39-testgroup Request for Comments: 19xx bill manning - editor Category: Experimental November 1995 Class A Subnet Experiment Results and Recommendations Status of this Memo This documents the experience the Internet community with the Experimental Protocol defined in RFC 1797. This does not specify an Internet standard of any kind. Continued discussion is requested. Distribution of this memo is unlimited. Discussion This memo documents some experiences with the RFC 1797 subnet A experiment and provides a number of recommendations on future direction for both the Internet Registries and the Operations community. Not all proposed experiments in RFC 1797 were done. Only the "case" one type delegations were made. Additional experimentation was done within the DNS service, by supporting a root nameserver and the primary for the domain from within the subnetted address space. In addition, testing was done on classless delegation[x]. Internet Services offered over the RFC 1797 experiment were: FingerD HTTPD Telnet FTP server/client Gopher DNS F.Root-Servers.Net, a root name server had an interface as part of the RFC 1797 experiment. Here is a report on it's performance: "My root server has processed 400,000,000 queries in the last 38 days, and well over half of them were to the temporary 39.13.229.241 address (note that I retained the old 192.5.5.241 address since I knew a lot of folks would not update their root.cache files and I didn't want to create a black hole.)" Inital predictions[x] seemed to indicate that the safest path is for an ISP is to have -all- of the ISP clients to be either: a) singly connected OR b) running a classless interior routing protocol Operations There were inital problems in at least one RIPE181 implementation. It is clear that operators need to register in the IRR all active or registered aggregates and delegations for any given prefix. Additionally, there need to be methods for determining who is authoritative for announcing any given prefix. It is expected that problems identified within the confines of this experiment may be applicable to RFC 1597 prefixes. Use of traceroute (LSRR) is critical for network troubleshooting. In current cisco IOS, coding the following statement will inhibit cross-provider troubleshooting: no ip source route In general, there are serious weaknesses in the Inter-Provider cooperation model and resultion of these problems are outside the scope of this document. Routing issues. If you have: ip route 39.1.28.0 255.255.255.0 router bgp 701 redistribute static then ciscos will, by default, promote any classfull subnet route to a full classfull route (supernet routes will be left alone). 1: ip route 39.1.28.0 255.255.255.0 router bgp 701 no auto-summary redistribute static 2: ip route 39.1.28.0 255.255.255.0 router bgp 701 network 39.1.28.0 mask 255.255.255.0 redistribute static route-map static-bgp route-map static-bgp match ip address 98 AGSs that have just partial routes (& a default) were problematic. Users of cisco gear currently need to code the following two statements: ip classless The implication of this directive is that it elmininates the idea that if you know how to talk to a subnet of a network, you know how to talk to ALL of the network. ip subnet-zero Ascend default behaviour will create an aggregate announcement. The problem turned out to be that we were using a classfull IGP (rip) between our Ascends and our ciscos. The Ascend was told to announce 39.1.28/24, but since rip can't do this, the Ascend instead sent 39/8. This meet the predictions that were made early on. there are actually three ways to solve the subnet A problem, as described with current cisco's software. Which of them applies will depend on what software version you have, but a workaround can be implemented for ancient (e.g. 8.X) version software. o Preferred solution: turn on "ip classless" in your routers and use a default route inside your AS. The "ip classless" command prevents the existence of a single "subnet" route from blocking access via the default route to other subnets of the same old-style network. o Workaround for 9.1 or later software where the "ip classless" command is not available: install a "default network route" like this: "ip route 39.0.0.0 255.0.0.0 next-hop" along the axis your default route would normally take. I think you can utilize the "recursive route lookups" so the "next-hop" may not actually need to be a directly connected neighbour -- you can e.g. point to a loopback interface on your border router. o Workaround for 9.0 or older software: create a "default subnet route": "ip route 39.x.y.0 next-hop" combined with "ip default-network 39.x.y.0", otherwise as the 9.1 fix. Both of the latter solutions rely on static routes, and in the long run these will be impossible to maintain. In some topologies the use of static routes can be a problem (e.g. if you have more than one possible exit point from your AS to choose from). Recommendations: The RFC 1797 experiment appears to have been a success. It is safe to start carving up "Class A" space, if the spaces are delegated according to normal IR conventions[x]. References: rfc1466bis rfc1797 draft-degroot draft-huston Security: Authors Info: -- --bill