- Test - lists.nanog.org

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

Re: Routing wars pending?
by Sean Doran 16 Nov '95

16 Nov '95

Owen - I direct you to Yakov Rekhter's various drafts and commentaries that underline the fact that address ownership is irrelevant. Prefixes are simply strings of bits. What's important is the routing system. The fact that you are registered in registry X as being the "owner" of prefix Y is completely irrelevant if pretty much the entire Internet is going to route X towards Z. Now, fortunately, people are working on systems which will keep histories of route announcements and withdrawals so we can see which direction any given prefix was routed towards on a more historical basis. This may be as helpful in solving disputes as it will be in debugging routing. Sean.

3 2

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

16 Nov '95

From: Alan Hannan <alan(a)gi.net> 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. Well, the 800 number problem was a little easier, since phone numbers are variable length, and the 800 number database maps the numbers into another phone number, which may be a 13-digit carrier-id+phone-number combo... They say get stuffed, and get a congress person to propose a bill that all IP numbers are portable. This bill passes. It could happen. Any thoughts? Exactly which court do they go to to get this enforced on non-US parts of the Internet? Noel

1 0

Re: Routing wars pending?
by Vadim Antonov 16 Nov '95

16 Nov '95

>A FQDN is NOT useable as an EID. The host is not the endpoint. Ok. FQDN + port number. The endpoint does not have to be *named*, btw. It is quite enough to disallow TCP sessions to survice change of source or destination TLA (which is more than enough to cover the change of service providers) or to keep track of address changes the same way the post service does (i.e. forward and ask the addressee to notify the sender). >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. Process migration is a lame excuse for building a whole new level of indirection and doing a hell lot of changes everywhere. And, magic cookie EID is *not necessary* for process migration (you may want to read rationale for TRAP). It can (and should) be done w/o it. No matter how you jump, the migration requires dynamical rebinding of EID->TLA, and the complexity of the task does not depend on the nature of EID. So why bother with extra level of indirection? It does not simplify anything, and like any extra layer anywhere only makes for a lot of headache (why do i think of ATM?). And then, there's a document describing how to do process migration w/o magic cookie EIDs, and so far nobody found a fundamental fault (or inherent inefficiency) in it. As i discussed that with Noel the aforementioned "architect's sense" came up :) The statement that migration is impossible w/o magic cookie EIDs amounts to the denial of the existance of the postal service. It does the two-level addressing (the EID is the identity of the addressee, the TLA is the postal address). When you move your magazines keep coming to you, right? Even if the "host" (i.e. home) didn't move with you. --vadim PS Computer science is the formalized branch of general bureaucratology.

1 0

Re: Routing wars pending?
by Vadim Antonov 16 Nov '95

16 Nov '95

Silly. We already *do have two namespaces*. One is EIDs in form of FQDNs. They are portable. Another is IPv4 addresses which aren't. How about fixing the real problem -- i.e. making renumbering easy and removing all hardwired addresses from the software? (And, yes, fixing DNS). The magic-cookie EID scheme is nothing more than more complexity to work around the broken implementations. That extra level of indirection is patently useless otherwise. Even funnier, implementation of magic cookie EIDs requires changes in exactly the same pieces of software which need to be changed to repair existing two-level scheme. Note that fixing DNS (and you *have* to do that anyway if you want to use intermediate EIDs) is a lot easier than replacing routers, and does not introduce compatibility problems at the transport level. Sorry, nobody managed to make any reasonable case pro magic-cookie EIDs as yet. The best rationale i've heard was from Noel who said that his "architect's sense" tells him so. Funny thing, a surgeon i know was at loss when i asked him about this function of organism, should be a new discovery in medicine. --vadim In regards to: >(Tim Bass) > Technically, the aggregation advocates were correct. Socially and > politically, aggregation on a global cooperative scale has problems. >(Noel) >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. This idea has been around *long* enough. When do we separate the name spaces? How about along with the IPng transition? -Mike

2 1

Re: AS690 advisory update
by ser-rr＠ser.bbnplanet.net 15 Nov '95

15 Nov '95

> In theory, this would be covered by moving AS279 from the AS macro > for MCI to the AS macro for UUnet. > > In current practice, because AS macros are not widely in use (and > aren't in our machine generated aut-num right now), this will have > to be coordinated among providers (like you send us a note saying > your entire AS has moved). > > The idea is that this doesn't happen all that often. If it does, > the AS macro is a decent way of handling it. So, this also goes for new ASes? And you're saying that everyone that peers with you should start using AS macros in addition to aut-nums to both add new ASes and re-arrange policy for old ones. How many AS macros are there now, in the radb, ans, and ripe RR's? [i left out mci because i know how many there are, especially since it is a split db ;-] Are the AS-macros only referenced recursively after parsing the aut-num, or are they to be applied to policy independantly? How is policy to be determined for AS5757, should someone start announcing it tommorrow? In other words, say this appeared in the RADB tonight: route: 206.197.210.0/24 descr: A route that can't get everywhere origin: AS5757 mnt-by: MAINT-AS5757 changed: kobi(a)kobi.edu 951114 source: RADB And someone, pick a provider, started announcing this to you tommorrow. Say Sprint. Would it be accepted? And why? _k > > > Elliot, > > > > > > Ignore the advisory. If AS2 is the origin, we will route traffic > > > for that particular prefix/masklen using the most common policy > > > already in place for routes in AS2. > > > > > > If the common policy is for us to send traffic destined for AS2 > > > via our peer AS1, we will continue to do so for the new prefix/masklen. > > > > > > Steve > > > > > > > > > > > > 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.

4 5