A very late draft...

bmanning at ISI.EDU bmanning at ISI.EDU
Thu Nov 16 19:45:50 UTC 1995

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.


   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 

   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:

	 FTP server/client

   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 address 
    (note that I retained the old 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
	 b) running a classless interior routing protocol


   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
        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).

        ip route
        router bgp 701
        no auto-summary
        redistribute static

        ip route
        router bgp 701
        network mask
        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 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


  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].




Authors Info:


More information about the NANOG mailing list