Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

A very late draft...

  • From: bmanning
  • Date: Thu Nov 16 15:31:24 1995
  • Posted-date: Thu, 16 Nov 1995 11:45:50 -0800 (PST)

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




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.