As per Relevance of the word experiment, we have this rfc below:











Network Working Group B. Manning,
Request for Comments: 1879
Category: Informational January 1996


Class A Subnet
Results and

Status of this

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

Discussion/

This memo documents some experiences with the RFC 1797 [1] subnet
experiment (performed by the Net39 Test Group (see credits))
provides a number of recommendations on future direction for both
Internet Registries and the Operations community

Not all proposed experiments in RFC 1797 were done. Only the "
one" type delegations were made. Additional experimentation was
within the DNS service, by supporting a root nameserver and
primary for the domain from within the subnetted address space.
addition, testing was done on classless delegation [2].

Internet Services offered over the RFC 1797 experiment were




FTP server/


lpr (and its ilk



F.Root-Servers.Net, a root name server had an interface defined
part of the RFC 1797 experiment. Attached is a report fragment
it's performance: "My root server has processed 400,000,000
in the last 38 days, and well over half of them were to the
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.
files and I didn't want to create a black hole.)" - Paul





Manning Informational [Page 1]

RFC 1879 Class A Subnet Experiment January 1996


Initial predictions [3] seemed to indicate that the safest path
an ISP that participates in such a routing system is to have -all-
the ISP clients be either

a) singly connected to one upstream

b) running a classless interior routing

It is also noted that a network with default route may not notice
has potential routing problems until it starts using subnets
traditional A's internally

Problems &



There were initial problems in at least one RIPE181 [4]
implementation. It is clear that operators need to register in
Internet Routing Registry (IRR) all active aggregates and
for any given prefix. Additionally, there need to be methods
determining who is authoritative for announcing any given prefix

It is expected that problems identified within the confines of
experiment are applicable to some RFC 1597 prefixes or any "natural
class "A" space

Use of traceroute (LSRR) was critical for network
during this experiment. In current cisco IOS, coding the
statement will disable LSRR and therefore inhibit cross-
troubleshooting

no ip source-

We recommend that this statement -NOT- be placed in active ISP
configurations

In general, there are serious weaknesses in the Inter-
cooperation model and resolution of these problems is outside
scope of this document. Perhaps the IEPG or any/all of the
or continental operations bodies [5] will take this as an action
for the continued health and viability of the Internet










Manning Informational [Page 2]

RFC 1879 Class A Subnet Experiment January 1996




A classic cisco configuration that has the following

ip route 39.1.28.0 255.255.255.0
router bgp 64000
redistribute

will, by default, promote any classful subnet route to a
classful route (supernet routes will be left alone). This
can be changed in at least the following two ways

1:
ip route 39.1.28.0 255.255.255.0
router bgp 64000
no auto-
redistribute

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-
....
access-list 98 deny 39.1.28.0 0.255.255.255
access-list 98 permit
....
route-map static-
match ip address 98

Users of cisco gear currently need to code the following
statements

ip
ip subnet-

The implication of the first directive is that it eliminates the
that if you know how to talk to a subnet of a network, you know
to talk to ALL of the network

The second is needed since it is no longer clear where the all-
or all-zeros networks are [6].

Other infrastructure gear exhibited similar or worse behaviour
Equipment that depends on use of a classful routing protocol, such
RIPv1 are prone to misconfiguration. Tested examples are
Ascend and Livingston gear, which continue to use RIPv1 as
default/only routing protocol. RIPv1 use will create an



Manning Informational [Page 3]

RFC 1879 Class A Subnet Experiment January 1996


announcement

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

This validates the predictions discussed in [3].

Cisco Specific

There are actually three ways to solve the unintended
problem, as described with current cisco IOS. Which of them
will depend on what software version is in the router.
can be implemented for ancient (e.g., 8.X) version software

o Preferred solution: turn on "ip classless" in
routers and use a default route inside the AS
The "ip classless" command prevents the existence
a single "subnet" route from blocking access via
default route to other subnets of the same old-style network
Default only works with single-homed ISPs

o Workaround for 9.1 or later software where
"ip classless" command is not available: install
"default network route" like this
"ip route 39.0.0.0 255.0.0.0 " along the
the default route would normally take. It
an ISP can utilize the "recursive route lookups"
the "next-hop" may not actually need to be a
connected neighbour -- the internal router can e.g.,
point to a loopback interface on the border router
This can become "really uncomfortably messy" and it
be necessary to use a distribute-list to
the announcement of the shorter mask

o Workaround for 9.0 or older software: create
"default subnet route": "ip route 39.x.y.0 "
combined with "ip default-network 39.x.y.0",
as the 9.1 fix

Both of the latter solutions rely on manual configuration, and in
long run these will be impossible to maintain. In some
the use of manual configuration can be a problem (e.g., if there



Manning Informational [Page 4]

RFC 1879 Class A Subnet Experiment January 1996


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
safe to start carving up "Class A" space, if the spaces are
according to normal IR conventions [7] and recommend the
consider this for future address delegations

Credits

Thanks to all the RFC 1797 participants. Particular thanks to
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
MindSpring. Especial thanks to Suzanne Woolf for cleanup

References

[1] IANA, "Class A Subnet Experiment", RFC 1797, USC/
Sciences Institute, April 1995.

[2] Eidnes, H., and G. J. de Groot, "Classless in-addr.
delegation", Work in Progress, SINTEF RUNIT, RIPE NCC, May 1995.

[3] Huston, G., "Observations on the use of Components of the Class
Address Space within the Internet", Work in Progress, AARnet,
1995.

[4] Bates, T., et.al, "Representation of IP Routing Policies in
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",
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.










Manning Informational [Page 5]

RFC 1879 Class A Subnet Experiment January 1996


Security

Security issues were not considered in this experiment

Editor's Address

Bill
Information Sciences
University of Southern
4676 Admiralty
Marina del Rey, CA 90292-6695


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



































Manning Informational [Page 6]








if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum