November 1995 - Test - lists.nanog.org

Like dogs, returning to thier own
by bmanning＠ISI.EDU 17 Nov '95

17 Nov '95

Here is round two... Last Chance B&G. It's off to the drafts directory in the early morn. (~14:00 UTC) TTFN..!! ---------------------------------------------- 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/Purpose This memo documents some experiences with the RFC 1797[1] 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[2]. Internet Services offered over the RFC 1797 experiment were: Finger HTTP Telnet FTP server/client Gopher 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 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 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. 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 .... route-map static-bgp match ip address 98 Users of cisco gear currently need to code the following two statements: ip classless ip subnet-zero The implication of the first directive is that it eliminates 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. The second is needed since it is no longer clear where the all-ones 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 a RIPv1 are prone to misconfiguration. Tested examples are current Ascend and Livingston gear, which continue to use RIPv1 as the default/only routing protocol. RIPv1 use will create an aggregate announcement. This pernicious use of this classful IGP was shown to impact otherwise capable systems. When attempting to communicate between an Ascend and a cisco the promotion problem identified above, was manifest. The problem turned out to be that a classful IGP (RIPv1) was being used between the Ascends and ciscos. The Ascend was told to announce 39.1.28/24, but since RIPv1 can't do this, the Ascend instead sent 39/8. We note that RIPv1, as with all classful IGPs should be considered historic. This validates the predictions discussed in [3]. Cisco Specific Examples There are actually three ways to solve the unintended aggregation problem, as described with current cisco IOS. Which of them applies will depend on what software version is in the router. Workarounds can be implemented for ancient (e.g. 8.X) version software. o Preferred solution: turn on "ip classless" in the routers and use a default route inside the 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. Default only works with single-homed ISPs. 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 the default route would normally take. It appears an ISP can utilize the "recursive route lookups" so the "next-hop" may not actually need to be a directly connected neighbour -- the internal router can e.g. point to a loopback interface on the 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 there is 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 it safe to start carving up "Class A" space, if the spaces are delegated according to normal IR conventions[7] and recommend the IANA consider this for future address delegations. Credits: Thanks to all the RFC 1797 participants. Particular thanks to Paul 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, ESnet, Xlink, SURFnet, STUPI, Connect-AU, INBEnet, SUNET, EUnet, InterPath, VIX.COM, MindSpring. Especial thanks to Suzanne for cleanup. References: [1] IANA, "Class A Subnet Experiment", RFC 1797, ISI, April 1995 [2] H. Eidnes, G. J. de Groot, "Classless in-addr.arpa delegation", Work in Progress, SINTEF RUNIT, RIPE NCC, May 1995 [3] G. Huston, "Observations on the use of Components of the Class A Address Space within the Internet", Work in Progress, AARnet, May 1995 [4] T. Bates, et.al, "Representation of IP Routing Policies in a Routing Registry", RFC 1786, MCI, March 1995 [5] http://info.ra.net/div7/ra/Ops.html, November 1995 [6] F. Baker, Editor, "Requirements for IP Version 4 Routers", RFC 1812, cisco systems, June 1995 [7] K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, "INTERNET REGISTRY GUIDELINES", Work in Progress, InterNIC, APNIC, RIPE, November 1995 Security Considerations: Security was not considered in this experiment. Editor Address: Bill Manning Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, CA 90292-6695 USA Phone: +1 310-822-1511 x387 Fax: +1 310-823-6714 EMail: bmanning(a)isi.edu -- --bill

3 2

Re: Routing wars pending?
by salo＠msc.edu 17 Nov '95

17 Nov '95

> From: Tim Bass (@NANOG-LIST) <nanog(a)dune.silkroad.com> > Subject: Re: Routing wars pending? > To: big-internet(a)munnari.oz.au > Date: Thu, 16 Nov 1995 23:39:20 -0500 (EST) > Cc: nanog(a)merit.edu > [...] > Only three? There are about double that amount I would like > to see you do differently, Paul. I just don't have the time > to always count the number of signatures nor worry when > others hit the group reply key in elm like you seem to. > [...] Personally, I would much prefer that you waste the time of some other mail list with this sort of chatter... -tjs

1 0

Re: Routing wars pending?
by Robert Moskowitz 16 Nov '95

16 Nov '95

At 08:22 PM 11/15/95 -0500, Vadim Antonov wrote: > >>Consider process migration. > >Any commercial OS out there which does process migration? Most >OS people became quite convinced that process migration does not >pay for itself. Vadim, In many areas you and Noel know a lot more than me. You are the eagles, I am only a hawk. But over in corporate networks, we have had much of this for years. In VTAM. Yes sessions do not survive rollovers, but reconnects go immediately to the new system. We have WORKED VERY HARD trying to manage this in DNS. Notify has helped and Dynamic will help more. But that is for host, not process. So we have to have multiple A records for different names and that breaks in-addr.arpa! GRRRRR...... Talk to my at Dallas and I will give you living examples of BBBIIIGGG mobile processes VERY mission critical..... Enough. I got to head over to the AIAG office. Talk to me about that also at Dallas. Robert Moskowitz Chrysler Corporation (810) 758-8212

5 4

Re: Routing wars pending?
by jnc＠ginger.lcs.mit.edu 16 Nov '95

16 Nov '95

<CIDRD is the wrong list for this: CIDRD is for *deployment*, not architectural debate. Please follow-up on Big-Internet.> From: Tim Bass Then, in parallel, CIDR was hailed as the 'way to help save B space [depletion] problems'. ... very surprised to learn that our vision of "completely portable" CIDR address space have been overshadowed by the success of CIDR in another problem area that only those with keen insight at the time could predict, routing table explosion. You keep saying this, but it is *NOT TRUE*. You didn't need "keen insight" to know it was coming, you only needed to be able to *read*, viz (from "Supernetting: an Address Assignment and Aggregation Strategy" RFC-1338, June 1992): As the Internet has evolved and grown over in recent years, it has become painfully evident that it is soon to face several serious scaling problems. These include: ... 2. Growth of routing tables in Internet routers beyond the ability of current software (and people) to effectively manage. ... It has become clear that the first two of these problems are likely to become critical within the next one to three years. This memo attempts to deal with these problems by proposing a mechanism ... So, the routing table problem was well known to be coming at the time that CIDR was under discussion, and the effects of CIDR on address allocation were pointed out in *great* detail in a discussion on the *main* IETF list (look in the archives for the thread "Re: Vote NO on R-L-G IP Address Allocation proposal", and in particular my message of "Sat Oct 31 19:26:04 1992", the infamous "fnortz" message, which pointed out in some detail why renumbering was inevitable). So, if anyone who are around then missed it, they have only themselves to blame. I am damned tired of people rewriting history. Please cease and desist before I become extremely upset. after all, CIRD was only to be an *interim solution* for a few years for B space depletion. IPv6 would take care of that. ... aggregation was now the accepted practice for solving most I problems and was not an *interium* or temporary fix, but was to be a core Internet solution. There is a certain amount of truth to this. CIDR did assume that some "better" fix was coming as part of IPng (and let's not forget, the CIDR debate predated the IPv6 debate - SIP only started to be discussed late that summer). However, as is now I hope obvious to everyone, it's impossible to have a single namespace which is both i) used directly for routing, and ii) identifies hosts directly. To get rid of "renumbering", the Internet needed to split "addresses" as host-identifiers from "addresses" as routing-names, and map one into another. No matter how hard I and some others argued for doing this, though, people didn't want to take that "radical" step of two namespaces. Everyone's moaning now about the painful consequences? Tough. (I take great delight in the fact that one of the principal opponents of splitting off the host-identification function is also one of the people most upset at renumbering. I expect by now, with hindsight to help his understanding along, the irony will have dawned on him.) Technically, the aggregation advocates were correct. Socially and politically, aggregation on a global cooperative scale has problems. Which is why we need *two* namespaces: one for the routing to do what mathematics forces it to, and one for the humans to be able to dork with. there are future social and political implementations of global aggregation that are negative. There are some very painful routing consequences, even with two separate name-spaces (e.g. things like inbound traffic bias), but these are technical problems which will only admit of technical fixes. We have to investigate various possible technical solutions, and weigh the costs of them against the benefit of doing it the way we'd like, but that debate has to be a purely technical one, *not* a policy debate. Now, let's see, where are my winterized, flame proof, long johns? After this email, I'm sure to need numerous layers :-) ;-) Hah! When I get *really* grumpy, you better have something better than miserable protective clothing! Try a bunker reinforced to +125 PSI blast overpressure! :-) Noel

9 8

Re: A very late draft...
by Paul Ferguson 16 Nov '95

16 Nov '95

Not meaning to pick nits, but this should read 'no ip source-route'. - paul At 11:45 AM 11/16/95 -0800, bmanning(a)ISI.EDU wrote: > 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 > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso(a)cisco.com c i s c o S y s t e m s

1 0

AS690 advisory update
by Steve Heimlich 16 Nov '95

16 Nov '95

Folks, As previously mentioned, ANS is moving to a new configuration system which will eliminate the need for registering AS690 advisories with RIPE-181 route objects. Our initial deployment described below has gone well, and as a result we will freeze our aut-num (currently still machine generated based on advisories) on Friday, 11/17, at midnight ET (Saturday, 11/18, 5am GMT). Tuesday morning's AS690 config run will use the frozen aut-num. After this time, AS690 advisories will be ignored. Policy toward routes registered in the IRR will be based solely on origin AS. The origin AS will be expanded to the set of route objects registered for that origin AS; the resulting list of prefixes will be used in generating router configurations, as today. Refinement of AS690 import policies will begin on a per AS basis next week, starting with large origin ASes. The human readable version of the 18,000 line AS690 aut-num is currently available at: ftp://ftp.ans.net/pub/info/routing-stats/aut-num-as-690 Steve -------- To: nanog(a)merit.edu Subject: AS690 policy configuration changes Date: Mon, 06 Nov 1995 18:43:22 -0500 From: Steve Heimlich <heimlich(a)kingbee.ans.net> All, Starting with Friday [11/10] morning's config run, AS690 will pick up any route listed in various routing registries, including both those routes with advisories and those routes without advisories. ANS customers will not be affected by this change. Routes without advisories will be examined for origin AS and will inherit the most popular policy currently used for that AS. For example, if a route for 147.225/16 (origin AS1660) were listed without an advisory, we would configure ourselves to listen for 147.225/16 in the same way that we listen to most other AS1660 routes (only from AS 1324 in this case). If a route is registered in an AS for which we don't have existing policy, it will not be routed. In the example above, if 147.225/16 were registered without an aggregate, and it were the only route registered with origin 1660, then we will not route it. We have a tool which flags such new ASes, and policy toward them will be created regularly. The rate of growth in number of ASes is not high, particularly relative to the rate of growth in number of routes. For now, we will continue to build our policy dynamically from the advisory attributes. Assuming that this hybrid deployment goes well, we intend to freeze our policy and convert to a system which ignores advisories altogether. With this system, the mechanics of shifting policy will be quite easy (essentially involving only ANS). I expect to announce that freeze and shift in the next week or so. At that point, those folks who want to strip AS690 advisories from any database may do so without a problem; as mentioned above, any advisories registered after that time will be ignored. Steve

4 5

A very late draft...
by bmanning＠ISI.EDU 16 Nov '95

16 Nov '95

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

1 0

Re: Routing wars pending?
by owen＠DeLong.SJ.CA.US 16 Nov '95

16 Nov '95

> Hm, routing wars. Fun stuff. Expect much heat on this shortly... :( > > Essentially, the point-of-appeal would probably be the IEPG > or NANOG mailing lists, and who would get believed would probably > get worked out after some protracted flameage, consultations with > lawyers, and arguments about how routing registry technologies > will save the planet from routing wars, pollution, and too-strong coffee. > > My own personal advice wrt people who are thinking of using > others' address space without permission is pretty simple: > don't do it, you'll lose. > > Sean. > Ah, but Sean, you missed the essential element of the previous post. Like so many other situations in the middle-east, you have two different factions, both of whom feel that they have legitimate title to the address space in question. Neither of them feels that it belongs to the other. Hence the conflict. The question boils down to who really does own the address space, and frankly, the fact that money changed hands causes me to lean more towads the person who paid. Owen

4 4

Re: Routing wars pending?
by ser-rr＠ser.bbnplanet.net 16 Nov '95

16 Nov '95

> > > Robert Elz <kre(a)munnari.OZ.AU> writes: > > > > What's needed is a list of just where routes should be accepted > > from - which equates pretty much with address owneship, though > > says nothing about the permanence of that ownership. > > A routing registry strongly coupled with an assignment registry: > The RIPE database. > > Daniel Unfortnately, those of us who aren't actual registries can't use the RIPE setup in quite the same fashion. Personally, I'd prefer to just run a RIPE-like RR, rather than running an RR and an RWhois server, or running an RR and sending in SWIPs all the time.... Unfortunately, the Internic doesn't quite seem to see it from my perspective. _k

1 0

Re: 800 numbers vs. IP addresses (was Routing wars pending?)
by Stephen Geis 16 Nov '95

16 Nov '95

Alan Hannan asked: > What are the correlations and contrasts between our current > backbone routing problems (wrt space and # of routes) and the FCC > decision several years ago to make 1-800 numbers portable. > There is a major difference between ownership of IP network numbers and telephone number portability: the economic benefits of ownership of addresses are not comparable to those of ownership of telephone numbers. As far as I know, the economic benefits of network number ownership are confined to cost avoidance related to re-numbering. A major argument for ownership of telephone numbers (and especially freephone - e.g., 800 - numbers) is that the subscriber makes an investment (by advertising, letterhead, etc) getting knowledge of a subscriber's phone number to customers, friends, and other correspondents. Since the knowledge (as used by humans) of how to reach a "subscriber" on the Internet is encoded in a DNS name and not in an address, no comparable argument can be made for ownership of addresses. Stephen Geis ITU geis(a)itu.ch

1 0