RFC 1879

Class A Subnet Experiment Results and Recommendations 🦋

okay bestie, so this is RFC 1879 💖 from the Network Working Group, published in January 1996. B. Manning is the Editor, writing from ISI. It's Category: Informational, so it's giving "here's some info for the Internet community" and nothing more 🎀. It doesn't list anything it obsoletes or updates, so no drama there ✨

Status of This Memo 📜

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited 💅

Discussion/Purpose 💬

okay so this memo spills the tea on the RFC 1797 [1] subnet A experiment, which was run by the Net39 Test Group (see credits 🧚). It also gives a bunch of recommendations for where the Internet Registries and the Operations community should go next 🔥

Not all the experiments proposed in RFC 1797 actually happened. Only the "case one" type delegations were made. There was extra experimenting in the DNS service, though, where they supported a root nameserver and the primary for the domain from inside the subnetted address space. They also tested classless delegation [2] 🌸

Internet Services offered over the RFC 1797 experiment were:

• Finger
• HTTP
• Telnet
• FTP server/client
• Gopher
• kerberos
• lpr (and its ilk)
• X
• DNS

F.Root-Servers.Net, a root name server, had an interface defined as part of the RFC 1797 experiment. Attached is a report fragment on it's performance, and honestly, it's iconic 😭

"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.)" - Paul Vixie

Early predictions [3] suggested the safest path for an ISP that joins a routing system like this is to have all of its ISP clients be either:

            a) singly connected to one upstream ISP
    OR
            b) running a classless interior routing protocol

It's also worth noting that a network with a default route might not notice it has potential routing problems until it starts using subnets of traditional A's internally. Lowkey sneaky 🙈

Problems & Solutions 🔧

Operations 🛠️

There were initial problems in at least one RIPE181 [4] implementation. It's super clear that operators need to register in the Internet Routing Registry (IRR) all active aggregates and delegations for any given prefix. Also, there need to be methods for figuring out who is authoritative for announcing any given prefix 🫶

Problems spotted inside this experiment are expected to apply to some RFC 1597 prefixes, or to any "natural" class "A" space ✨

Using traceroute (LSRR) was critical for network troubleshooting during this experiment. In current cisco IOS, typing the following statement will disable LSRR, which means cross-provider troubleshooting gets blocked 💀

no ip source-route

We recommend that this statement not be placed in active ISP cisco configurations. Do not do it, bestie 🙅‍♀️

Honestly, there are serious weaknesses in the Inter-Provider cooperation model, and fixing them is outside the scope of this document. Maybe the IEPG or any/all of the national or continental operations bodies [5] will take this as an action item for the continued health and viability of the Internet 🌈

Routing 🛣️

A classic cisco configuration with the following statements:

ip route 39.1.28.0 255.255.255.0
router bgp 64000
redistribute static

will, by default, promote any classful subnet route to a full classful route (supernet routes get left alone). This behaviour can be changed in at least these two ways:

1:

ip route 39.1.28.0 255.255.255.0
router bgp 64000
no auto-summary
redistribute static

2:

ip route 39.1.28.0 255.255.255.0
router bgp 64000
network 39.1.28.0 mask 255.255.255.0
redistribute static route-map static-bgp
....
access-list 98 deny 39.1.28.0 0.255.255.255
access-list 98 permit any
....
route-map static-bgp
match ip address 98

Users of cisco gear currently need to code the following two statements:

ip classless
ip subnet-zero

The first directive basically kills 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. Main character energy has changed, bestie 💅

The second one is needed because it's no longer clear where the all-ones or all-zeros networks are [6] 🤷‍♀️

Other infrastructure gear showed similar or worse behaviour. Equipment that depends on a classful routing protocol, such as RIPv1, is prone to misconfiguration. Tested examples include current Ascend and Livingston gear, which keep using RIPv1 as the default/only routing protocol. RIPv1 use will create an aggregate announcement 😬

This pernicious use of a classful IGP was shown to impact otherwise capable systems. When an Ascend tried to talk to a cisco, the promotion problem from above showed up. The problem turned out to be that a classful IGP (RIPv1) was being used between the Ascends and the ciscos. The Ascend was told to announce 39.1.28/24, but since RIPv1 can't do this, the Ascend instead sent 39/8. We note that RIPv1, as with all classful IGPs, should be considered historic. Bye, RIPv1 🥀

This validates the predictions discussed in [3] 🧚

Cisco Specific Examples 🍒

There are actually three ways to solve the unintended aggregation problem with current cisco IOS. Which one applies depends on what software version is in the router. Workarounds can be implemented for ancient (e.g., 8.X) version software 🦖

• Preferred solution: turn on "ip classless" in the routers and use a default route inside the AS. The "ip classless" command stops a single "subnet" route from blocking access via the default route to other subnets of the same old-style network. Default only works with single-homed ISPs 👑
• 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 the default route would normally take. It appears an ISP can use "recursive route lookups", so the "next-hop" may not actually need to be a directly connected neighbour. The internal router can, e.g., point to a loopback interface on the border router. This can get "really uncomfortably messy", and it may be necessary to use a distribute-list to stop the shorter mask from being announced 🍓
• 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 the same as the 9.1 fix 🎀

Both of the latter solutions rely on manual configuration, and in the long run these will be impossible to maintain 😭 In some topologies, manual configuration can be a problem (e.g., if there is more than one possible exit point from the AS to choose from).

Recommendations 🎯

The RFC 1797 experiment appears to have been a success! We believe it's safe to start carving up "Class A" space, if the spaces are delegated according to normal IR conventions [7]. We also recommend the IANA consider this for future address delegations. Slay 💖

Credits 🫶

Thanks to all the RFC 1797 participants! Particular thanks to Paul Vixie, Geert Jan de Groot, and the Staff of the IETF33 Terminal room. Other thanks to ACES, MCI, Alternet, IIJ, UUNET-Canada, Nothwestnet, BBN-Planet, cisco systems, RIPE, RIPE NCC, ESnet, Xlink, SURFnet, STUPI, Connect-AU, INBEnet, SUNET, EUnet, InterPath, VIX.COM, and MindSpring. Especial thanks to Suzanne Woolf for cleanup 🌸

References 📚

• [1] IANA, "Class A Subnet Experiment", RFC 1797, USC/Information Sciences Institute, April 1995.
• [2] Eidnes, H., and G. J. de Groot, "Classless in-addr.arpa delegation", Work in Progress, SINTEF RUNIT, RIPE NCC, May 1995.
• [3] Huston, G., "Observations on the use of Components of the Class A Address Space within the Internet", Work in Progress, AARnet, May 1995.
• [4] Bates, T., et.al, "Representation of IP Routing Policies in a Routing Registry", RFC 1786, MCI, March 1995.
• [5] http://info.ra.net/div7/ra/Ops.html, November 1995.
• [6] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC 1812, cisco systems, June 1995.
• [7] Hubbard, K., Kosters, M., Conrad, D., and D. Karrenberg, "Internet Registry Guidelines", Work in Progress, InterNIC, APNIC, RIPE, November 1995.

Security Considerations 🔒

Security issues were not considered in this experiment. Bestie, this is the part that makes me nervous 😭🙈

Editor's Address 📬

Bill Manning
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, CA 90292-6695
USA

Phone: +1 310-822-1511 x387
Fax:   +1 310-823-6714
EMail: bmanning@isi.edu

---

That's the whole tea, bestie! 🌈💅✨