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