Class A Subnet Experiment Results and Recommendations
RFC 1879
Document | Type |
RFC - Informational
(January 1996; No errata)
Was draft-manning-classa-exp (individual)
|
|
---|---|---|---|
Author | Bill Manning | ||
Last updated | 2013-03-02 | ||
Stream | Legacy stream | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1879 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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. Discussion/Purpose This memo documents some experiences with the RFC 1797 [1] 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 [2]. Internet Services offered over the RFC 1797 experiment were: Finger HTTP Telnet FTP server/client Gopher kerberos lpr (and its ilk) X DNS 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 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.)" - Paul Vixie Manning Informational [Page 1] RFC 1879 Class A Subnet Experiment January 1996 Initial predictions [3] 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 OR 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 Operations There were initial problems in at least one RIPE181 [4] 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-provider troubleshooting: no ip source-route We recommend that this statement -NOT- be placed in active ISP cisco configurations. In general, there are serious weaknesses in the Inter-Provider cooperation model and resolution of these problems is outside the scope of this document. Perhaps the IEPG or any/all of the national or continental operations bodies [5] will take this as an action item for the continued health and viability of the Internet. Manning Informational [Page 2] RFC 1879 Class A Subnet Experiment January 1996 Routing A classic cisco configuration that has the following statements ip route 39.1.28.0 255.255.255.0 router bgp 64000 redistribute static will, by default, promote any classful subnet route to a full classful route (supernet routes will be left alone). This behaviour 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-summary redistribute static 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-bgp .... access-list 98 deny 39.1.28.0 0.255.255.255 access-list 98 permit any .... route-map static-bgp match ip address 98 Users of cisco gear currently need to code the following two statements: ip classless ip subnet-zeroShow full document text