Class A Subnet Experiment Results and Recommendations (RFC1879)
Original Publication Date: 1996-Jan-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
Status of this Memo
Network Working Group B. Manning, Editor
Request for Comments: 1879 ISI
Category: Informational January 1996
Class A Subnet Experiment
Results and Recommendations
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.
This memo documents some experiences with the RFC 1797  subnet A
experiment (performed by the Net39 Test Group (see credits)) 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 .
Internet Services offered over the RFC 1797 experiment were:
lpr (and its ilk)
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: "My root server has processed 400,000,000 queries
in the last 38 days, and well over half of them were to the temporary
220.127.116.11 address (note that I retained the old 18.104.22.168
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
Initial predictions  seemed to indicate that the safest path for
an ISP that participates in such a routing system is to have -all- of
the ISP clients be either:
a) singly connected to one upstream ISP
b) running a classless interior routing protocol
It is also noted that a network with default route may not notice it
has potential routing problems until it starts using subnets of
traditional A's internally.
Problems & Solutions
There were initial problems in at least one RIPE181 
implementation. It is clear that operators need to register in the
Internet Routing Registry (IRR) all active 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 are applicable to some RFC 1597 prefixes or any "natural"
class "A" space.
Use of traceroute (LSRR) was critical for network troubleshooting
during this experiment. In current cisco IOS, coding the following
statement will disable LSRR and therefore inhibit cross-pr...