- Test - lists.nanog.org

Re: Comments on draft-ietf-cidrd-ownership-01.txt
by jnc＠ginger.lcs.mit.edu 24 Aug '95

24 Aug '95

From: Dave Crocker <dcrocker(a)brandenburg.com> Last week I sent detailed comments on the "Ownership" I-D to the cidrd mailing list. Your document has many problems. Here are a few: The document goes on to describe the nature and benefits of hierarchical addressing. It then, incorrectly, asserts that the Internet topology reflects a hierarchy and that addresses must be kept aligned with the hierarchy. Well, in fact it says that "the topology of the network is not strictly hierarchical". I suppose you could read that as saying that the network topology is basically hierarchical, but it turns out this is a moot point. You appear to have missed the distinction between a hierarchical topology, and an address hierarchy. One can apply hierarchical addressing to a perfectly regular topology, e.g. a North-East-West-South mesh in which each node has precisely four neighbours. (True, one doesn't need full-blown dynamic routing for that case, but it's a useful test case.) This disproves your implicit suggestion that one cannot use hierarchical routing in a network which does not have a hierarchical topology. This requirement is used to assert the need for enforcing addressing changes when (some) topological changes take place. The point remains that use of hierarchical addressing is the *only* way known to control the growth of routing overhead costs in a very large network, and that an addressing hierarchy that is loosely isomorphic to the conectivity topology is the *only* one that will do that. As such, if it of course true that as the topology changes, the addressing hierarchy will have to, as well. The document makes no effort to deal with the very real difficulties this model creates for multi-homed organizations Multi-homing provides extra capability, but it does not come without a cost (in terms of routing overhead), and this is true no matter which addressing scheme is used. Since this topic is lengthy and complex, I will pass on. The document asserts the model of customer "leasing" of addressing rather than "owning" them but does not discuss the problems this creates with large-scale requirements for renumbering, generally viewed as difficult, but potentially quite insidious for local providers who change transit providers. Renumbering is indeed painful. However, given past decisions, no other option is now available to us if we wish the keep the Internet i) growing, and ii) functioning. In the next paragraph the paper states the importance of having an address reflect the topology of the network. Since the Internet is not a simple tree, but instead is a messy mesh one must ask by what procrustean process the Internet is to be represented by (relatively) stable hierarchical addresses? Exactly. There is no way to represent a dynamic topology like the Internet with stable hierachical addresses. The paper also says that changing an address is required as the network topology changes. This simply isn't true ... Internet topology changes all the time and sites are not required to change their addresses. At best this paragraph is seriously imprecise. At worst it is seriously wrong. This is a subtle and complex technical point, one that is not possible to quantify, and certainly not in a paper intended for a non-technical audience. A given address hierarchy, for a given topology, will produce a certain degree of routing overhead (as well as non-optimal routes). If the topology is then changed, wihtout changing the addressing, the routing overhead will grow. Eventually, it will grow to the degree that changes to the address hierarchy are needed to bring routing overhead back to reasonable bounds. The problem is exactly that no single change is deadly, but rather it is the accumulation of many small changes that cannot be supported. The end effect is to aid in the myth of Internet topological hierarchy. There is no myth of toplogical hierarchy that I know of, except in this paper. The first paragraph cites concerns for routing system scaling. However there is no concern expressed for Internet local providers or users. Presumably, an Internet which no longer worked because of routing system scaling problems would be a severe concern for Internet local providers or users. It is time to consider alternatives to CIDR. Unfortunately, it's too late to consider alternatives. The Internet has a real problem with routing table growth. To get something organized (since the solution to this problem cannot be imposed piecemeal, but has to be applied throughout the core), implemented, and deployed, will take at least a year, I would guess, and probably a fair amount longer. (It took almost 3 years to get CIDR, a relatively simple solution, deployed, BTW.) We don't have that time. CIDR was chosen with the expectation that it would be a sufficient near-term answer for routing table compression. CIDR was intended to handle "[growth] of routing tables in Internet routers beyond the ability of current software, hardware, and people to effectively manage". It indicated that "[the] proposed solution is to topologically allocate future IP address assignment". That is what we are doing now. After some considerable initial success it is proving inadequate. No, it's perfectly adequate, just painful. However, no other tool is available to handle growth in the network. The Internet, to use my favourite analogy, is in the position of some who has jumped off a 50-story building, and about the 10th story decides it's going to hurt. Bit late now, guys... Noel

1 0

Pittsburgh directions
by Pam Ciesla 23 Aug '95

23 Aug '95

Can be found on the Web http://www.psc.edu/~kbiscan/home.html. If you need directions by e-mail let me know and I can send them. I will be out of the office until Monday, 8/28. Pam Ciesla

1 0

Comments on draft-ietf-cidrd-ownership-01.txt
by Dave Crocker 23 Aug '95

23 Aug '95

Folks, Last week I sent detailed comments on the "Ownership" I-D to the cidrd mailing list. Scott Bradner (Ops AD) asked me to submit the comments that I wrote as an I-D for wider dissemination. I added an introduction (summary) and an ending (recommendations) around the original comments on the Ownership (leasing) proposal. >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the CIDR Deployment Working Group >of the IETF. > > Title : The Myth of Topological Hierarchy: Comments on > <draft-ietf-cidrd-ownership-01.txt> > Author(s) : D. Crocker > Filename : draft-ietf-cidrd-myth-00.txt > Pages : 4 > Date : 08/22/1995 > >This note offers comments on the technical and operational aspects of the >proposal for large-scale use of "address leasing" recommended in "On the >Implications of Address Ownership for Internet Routing", I-D ><draft-ietf-cidrd-ownership-01.txt>, by Rekhter & Li. The draft has been >produced within the cidrd working group and is intended for publication as >a Best Current Practices official IETF document. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-cidrd-myth-00.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-cidrd-myth-00.txt -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker(a)brandenburg.com

2 1

Short walk off a Long PIER
by bmanning＠ISI.EDU 22 Aug '95

22 Aug '95

We would like to host an BOF on this whole renumbering thing. The paperwork is wending its way through the IETF now, but thought you would like to know. Proceedures for Internet and Enterprise Renumbering (PIER) Charter Chair(s) Bill Manning <bmanning(a)isi.edu> Roger Fajman <raf(a)cu.nih.gov> Area Director(s) Scott Bradner <sob(a)harvard.edu> Mike O'Dell <mo(a)uunet.uu.net> Mailing List Information General Discussion: pier(a)isi.edu To Un/Subscribe: pier-request(a)isi.edu Archive ftp://ftp.isi.edu/pier-archive Description of Working Group PIER will fill the niche between the ADDRCONF, CIDRD and DNSIND working groups in identifying processes and procedures, tools and techniques for renumbering in both the IPv4 and IPv6 environments. Emphasis will be placed on identifying the places where hardcoded IP addreses are used and documenting those places. If there are viable alternatives to hardcoded IP addresses, the working group will document those as well. The end results of these investigations will be a series of documents on renumbering issues and recommendations on what actions might be taken to address those issues where there is no currently viable alternative. These recommendations will be to other working groups and/or areas regarding possible improvements to protocols that would aid in renumbering. The PIER working group will not develop such protocols itself. --bill

1 0

New Tool Announcement: CiscoBGP
by labovit＠MERIT.EDU 22 Aug '95

22 Aug '95

The following README is also available on at: http://www.ra.net/routing.arbiter/RA/RADB.tools.docs/cisco.html ----------------------------------------------------------------------- Cisco Version 2 READ.ME Last updated 8-21-95 CiscoBGP obtains and analyzes routing information from production Ciscos, and compares the data with routes in the Routing Arbiter Database. The software also flags prefixes that are reserved by RFC1597. An alpha version is available from: ftp://ftp.ra.net/routing.arbiter/radb/tools/cisco.02.tar.Z Two scripts are provided with CiscoBGP. Cisco_fetch takes the Cisco's IP address and password as input, automatically sets up a telnet session to the router, issues a 'show ip bgp' command, and dumps the BGP routing tables to standard out on the local workstation. Usage is as follows: cisco_fetch hostname password enable_password The cisco_check script then processes the 'show ip bgp' output and lists prefixes with AS origins different than those registered in the IRR. Usage is as follows: cisco_check inputfile This command produces output in this format: 0.0.0.0 [????] 6503 185 i 12.0.0.0 [????] 6503 185 3561 701 i 35.42.1.0/24 [237] 6503 185 i 39.2.254.0 [????] 6503 185 3561 1133 1128 2043 766 i 39.7.8.0 [????] 6503 185 3561 1800 i 39.7.88.0 [????] 6503 185 3561 1800 1883 1880 i 39.7.90.0 [????] 6503 185 3561 1800 1883 1880 1882 i 39.11.6.0 [????] 6503 185 3561 1849 2822 i 39.13.135.0 [????] 6503 185 3561 1239 1795 3463 i 39.13.229.0 [????] 6503 185 3561 701 3557 i 128.35.0.0 [560] 6503 185 3561 560 701 6 i 128.60.0.0 [86] 6503 185 3561 86 48 i 128.91.0.0 [3576] 6503 185 3561 690 1324 1336 55 i 128.122.0.0 [1785] 6503 185 3561 1239 1785 3973 12 i 128.140.0.0 [279] 6503 185 3561 279 3591 i 128.151.0.0 [1785] 6503 185 3561 1239 1785 20 i If the origin AS differs from the origin registered in the RADB, the correct origin is given in brackets. '?????' indicates that the route object for a given prefix is not registered in the IRR. Send comments about the software to ra-team(a)merit.edu. -- Craig Labovitz labovit(a)merit.edu Merit Network, Inc. 4251 Plymouth Road, Suite C. (313) 764-0252 (office) Ann Arbor, MI 48105 (313) 747-3745 (fax)

1 0

CIDR FAQ - V2
by Hank Nussbacher 21 Aug '95

21 Aug '95

All followups to cidrd only plz... ------------------------------------------------------------------------ The CIDR FAQ | Version 2 | 21 August 1995 ------------------------------------------------------------------------ The following document is a collection of Frequently Asked Questions about CIDR. This document is not meant to be a networking/routing guide and tutorial. Where appropriate pointers to other documents of a more general nature have been mentioned. Updates from a previous version are marked with a '|' in column 1. If you have any questions you would like added, please send them to the editor mentioned below: Hank Nussbacher (Tel Aviv University and IBM Israel) hank(a)vm.tau.ac.il or hank(a)ibm.net.il If you would like to "discuss" items from this FAQ please send your mail to cidrd(a)iepg.org This FAQ is being distributed to the following groups and lists: alt.internet.services alt.internet.access.wanted nanog(a)merit.edu inet-access(a)earth.com iap(a)vma.cc.nd.edu local-ir(a)ripe.net cidrd(a)iepg.org To retrieve the most up-to-date version of this document: - anonymous FTP: ftp.ibm.net.il/pub/docs/cidr.faq ------------------------------------------------------------------------ General questions ----------------- 1. What does CIDR stand for? CIDR stands for Classless Inter-Domain Routing and is documented in RFC1517/1518/1519/1520. CIDR is an effective method to stem the tide of IP address allocation as well as routing table overflow. Without CIDR having been implemented in 1994 & 1995, the Internet would not be functioning today. Basically, CIDR eliminates the concept of class A, B, and C networks and replaces this with a generalized "IP prefix". CIDR can be used to perform route aggregation in which a single route can cover the address space of several "old-style" network numbers and thus replace a lot of old routes. This lessens the local administrative burden of updating external routing, saves routing table space in all backbone routers and reduces route | flapping (rapid changes in routes), and thus CPU load, in all | backbone routers. CIDR will also allow delegation of pieces of what use d to be called "network numbers" to customers, and therefore make it possible to utilize the available address space more efficiently. See question #6 below for details on "IP prefix"s. 2. What is an ASN? ASN stands for Autonomous System Number and acts to merge many networks into a logical domain. 3. What is BGP? BGP stands for Border Gateway Protocol and is the de-facto standard for routing between Autonomous Systems in the Internet. All communications between Internet Service Providers (ISP) is handled via BGP4 which supports CIDR. 4. Why should I make the effort and convert my routing to be CIDRized? The routing tables in the Internet have been growing as fast as the Internet and the router technology specifically and computer technology in general has not been able to keep pace. In December 1990 there were 2190 routes and 2 years later there were over 8500 routes. In July 1995 there are now over | 29,000 routes, which require approximately 10 MB in a router with a | single peer. Routers at interconnection points (or multi-homed | hosts doing full routing with many peers) receive these routes from | several peers, and need several dozen megabytes of RAM (and the | appropriate CPU horsepower) to handle this. A list of those routers | that can handle this appears at the end of this question. Routers with 64MB of memory have the capacity for approximately 60,000 routes after which some routes will just have to be left out of the global routing tables, and the more likely ones to be left out are routes covering small pieces of address space. Without the CIDRization work that has gone on for the past 2 years the routing tables would be in excess of 65,000 routes. By CIDRizing you help the Internet reduce the routing overload as well as increasing the liklihood that in the future your routes will be carried by all ISPs. The major benefit of CIDR is to allow for continuous, uninterrupted growth of the Internet. For a significant percentage of sites connected to the Internet the value of the Internet increases with the total number of sites connected to the Internet. Therefore, taking steps needed to allow for continuous uninterrupted growth (like CIDRizing, or renumbering) is beneficial to such sites. The routers today that are available to handle the full routing table are: | cisco 7000 w/ 64Mb cisco 4500 w/ 32Mb | IBM ENSS w/ 64Mb | BayNetworks models AN/ASN/BLN/BCN w/ 32Mb 5. Can you give an example of a simple CIDR configuration for a cisco router? The following example creates 2 aggregates and suppresses any more specific addresses that may be contained within those aggregates. The access-list causes only those nets to be distributed as listed, and not any others that may exist in the BGP routing tables. router bgp 64100 no synchronization aggregate-address 172.16.0.0 255.248.0.0 summary-only aggregate-address 192.168.50.0 255.255.255.0 summary-only neighbor 192.168.54.2 remote-as 65000 neighbor 192.168.54.2 distribute-list 12 out default-metric 70 ! access-list 12 permit 192.168.50.0 0.0.0.255 access-list 12 permit 172.16.0.0 0.7.255.255 An alternate method is via network and route statements: router bgp 64100 no synchronization network 172.16.0.0 mask 255.248.0.0 network 192.168.50.0 mask 255.255.255.0 neighbor 192.168.54.2 remote-as 65000 neighbor 192.168.54.2 default-metric 70 ip route 172.16.0.0 255.248.0.0 Null0 254 ip route 192.168.50.0 255.255.255.0 Null0 254 In this case, only those routes explicitly mentioned in "network" statements will be announced with BGP. For these routes to be announced, there has to be a corresponding route in the IP forwarding table, thus the need to create the static routes. The static routes will also serve as "pull-ups" for the route advertisements and thus prevent route flapping: these routes will always be announced with BGP by this router. Note that as long as more specific routes exist internally in your network, these will be used in preference to the static "less specific" route entries (longest prefix matching is being used). A good rule to follow is to never redistribute IGP learnt routes directly into BGP, but to rather use network or aggregate-address statements. And if you must redistribute dynamically learnt IGP routes into BGP, you MUST use filtering. The reasons for this advice are several, some of which are: 1) if your IGP is classful (e.g. RIP or IGRP) you will by default not do any route aggregation 2) if you have an internal stability problem (accidents do happen), this will be reflected as a "route flap" in the whole routing system, globally burning CPU cycles better spent on other things 3) if the IGP -> BGP transition is unrestricted, this can lead to false routing information escaping from your network (especially if you do not fully have administrative control over your IGP) 6. What do all these /16s and /24s mean in my BGP tables? This refers to the number of bits of the network part of the IP address. A former class B may appear as 172.50.0.0/16, which is the same as 256 class C's which can appear as 192.200.0.0/16. A single class C appears as 192.201.1.0/24. These "things" are often called an "IP prefix", which consists of an IP address and a mask length. The mask length specifies the number of leftmost contiguous significant bits in the corresponding IP address. Thus, an IP prefix with a prefix length of 15 (denoted /15) covers the address space of 128k IP addresses, and a /17 covers the address space of 32k IP addresses. Here is a table of the more popular CIDR blocks: # of former CIDR class C block nets ---- ---- /27 1/8 /26 1/4 /25 1/2 /24 1 /23 2 /22 4 /21 8 /20 16 /19 32 /18 64 /17 128 /16 256 = 1 former class B /15 512 /14 1024 /13 2048 In general, advertising a prefix covering less address space than a /24 prefix will probably not get into the global routing tables, and global Internet connectivity is less likely to happen. Note that for you as an administrator of an AS, it is a good idea to announce as few prefixes as possible and to utilize the address space as much as possible. 7. Do I need to carry the full Internet routing table? When would it be necessary? What routers on the Internet carry full routing tables and how much memory is needed? No you do not need to carry the full Internet routing table. If you are single-homed, meaning you have a single connection to an ISP, then all you need to do is point a default route to the ISP and tell your ISP not to send you the full routing table. If you are multi-homed, you will want to know which nets to route via connection A and which nets to route via connection B. The easiest way to do this is to request a partial routing table from one ISP - with those nets that are closest to them, and default everything else to the other ISP. This way your routing tables need not contain the entire Internet universe but only a small subset. The closer you get to the hub or nexus of the Internet, the larger your routing tables need to be. For example, those connected to public exchange points (like the NAPs, CIX, STIX, LINX, dGIX) in general, carry full routing tables and run without a default route. 8. What is there in the Internet to stop me from making a mistake and announcing via BGP an aggregate that is larger than the nets I am in charge of? In principle there is nothing to stop you. The responsibility falls on both ends of the BGP link - you are responsible to filter what you announce and the receiving end - if it has its act together - filters also what it *thinks* it should be hearing from you so as prevent mistakes on your part. Those sites that do not work with access lists and filters and just readily accept what is sent to them are just waiting for a problem to happen. Filtering can either be done at the IP network level or at the BGP path (BGP orgin AS) level. See question 20 below for details on a tool to assist in filtering. 9. Who has to renumber with CIDR ? Sites that move from one ISP to another, and who had been allocated addresses from their original ISP's CIDR block, in all likelihood will have to return those addresses as part of the move. The reason is to keep the number of prefixes in the global routing system within the limits of current technology. Specific questions ------------------ 10. I have a /16 but have registered parts of it as /24s in the RADB. I now want to CIDRize. The problem is parts of the /16s are missing and are routed via a different ASN. Can you explain how more specific routes override more general ones and will I hurt my routing if I just advertise the /16 and not a bunch of /20s and /21s? There are two aspects to the answer: 1) Real (BGP) world: Given there are several AS's sharing addresses out of a /16 prefix, every AS should advertise exactly those prefixes which it is really originating. However, if there is one AS "originating" a significant majority of this address space, the concerned AS's might agree that this one and only advertises the /16 and all others their more specifics. The more specifics always take precedence over the less specific. 2) Routing registry: The registry DB, of course, should always reflect reality. If in the above example the AS's agree on the "big AS" announcing the /16, the "big AS" should document with the route-object that it's not really originating the whole aggregate by using "hole" attributes (see ripe.181, 5. The Route Object). 11. How can I redistribute our IGP routes (IGRP) so that they become aggregated when sent out via BGP? It is strongly discouraged to redistribute IGPs into BGP, because local IGP configuration errors might easily corrupt routing information of the whole Internet. If, however, you have to do it anyway, you MUST use strict distribute-lists with explicit permits (or route-maps) for redistribution. Here is an example for a Cisco configuration: router bgp 64100 aggregate-address 192.168.0.0 255.255.192.0 summary-only aggregate-address 172.16.0.0 255.254.0.0 summary-only redistribute igrp 64100 route-map origin-AS64100 ! ! or: ! redistribute igrp 64100 ! distribute-list 10 out igrp 64100 ! route-map origin-AS64100 permit 10 match ip address 10 ! access-list 10 permit 192.168.0.0 0.0.63.0 access-list 10 permit 172.16.0.0 access-list 10 permit 172.17.0.0 This example would generate one route 192.168/18 and one route 172.16/15 if any of the contained networks is in the IGP. 12. I am multihomed to three ISPs and can only CIDRize to two of them but to the third I need to still announce specific nets. What damage will this do to my AS? No damage can be done if the non-CIDR peer does not further announce your specifics to the global Internet. If your non-CIDR ISP DOES announce your specifics to the global Internet those specifics will have preference over the less specifics and therefore all traffic to you will get routed through the non-CIDR ISP. 13. I don't want to CIDRize. Can someone do proxy aggregation for me? Proxy aggregation should only be done with great care and should be avoided if you are not single-homed ! If you are single-homed ask your ISP. | Others may proxy aggregate over your address range without your | consent, and send your traffic over paths/links not of your | choosing. Use of Routing Registries may help to identify and | correct these problem areas. |14. What routers on the market today do support CIDR (classless | routing)? | Routers that are capable of handling CIDR are: | | - all Cisco routers running 10.0 or higher | - all Bay Networks routers running 8.01 or higher | - 3Com Netbuilder II and Netbuilder Remote Office | - Telebit EMPB | - Unix w/ BSD/OS 2.0 w/ gated 3.5alpha_11 + radix-fixes | - IBM 2210 routers 15. How do I reach other parts of a subnetted old-style network when I have only partial routing information for that same old-style network?" There are actually three ways to solve this particular problem with Cisco's software. Which of them applies will depend on what software version is involved: 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. 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). Supplemental information ------------------------ The following information is presented as supplemental information that is related to the CIDRization process. 16. What is the Internet Routing Registry? The IRR is a way for ASN's to publicize their own intended routing policies without having to request a change from a go-between. | The RAdb which stands for the Routing Arbiter Data Base, which is part of the IRR, is part of a joint project between Merit and ISI. For full details contact: http://www.ra.net/routing.arbiter/RA/index.html. The Routing Arbiter is a project of the US National Science Foundation. As part of that project, it runs a routing registry database. That database (the RAdb) forms part of the IRR collection of databases. The RIPE database is not part of the RAdb but does participate in the IRR. At present, there are five entities that contribute to the IRR effort and more are expected. Today, all the contributing registries use the RIPE-181 database format. | All IRR participants can be contacted via automail handlers that accept batch updates via email. An example of a routing update appears below: password: xxxxxxxx *rt: 138.134.0.0/16 *de: NET-IEC *or: AS378 *mb: AS378-MNT *ch: hank(a)aristo.tau.ac.il 950724 *so: RIPE The *rt: tag identifies the net and the routing policy is based on *or: tag. An example of a routing policy is presented below: aut-num: AS378 descr: ILAN descr: Israeli Academic and Research Network as-in: from AS1755 100 accept ANY as-in: from AS174 100 accept ANY as-in: from AS3339 100 accept AS3339 as-out: to AS1755 announce AS378 AS3339 as-out: to AS174 announce AS378 AS3339 as-out: to AS3339 announce ANY default: AS174 10 default: AS1755 20 default: AS3339 30 guardian: HANK(a)vm.biu.ac.il mnt-by: AS378-MNT admin-c: Hank Nussbacher tech-c: Hank Nussbacher changed: hank(a)vm.tau.ac.il 950627 source: RIPE For further details read over ripe-120.ps, ripe-121.ps and ripe-181.ps (via anonymous ftp from info.ripe.net/ripe/docs) 17. How do I update the registered routing information for my ASN? You need to submit a "route" object update and perhaps an "aut-num" object update (see examples above). Route objects add new nets to your autonomous system (or you can remove nets from your autonomous system) and the Autonomous-system object describes the type of routing you wish to have. 18. Which Routing database takes precedence? RIPE? RADB? MCI? Do I have to update all of them? | Each provider is allowed to select the preference order for | authentic data. For example, ANS uses the following precedence: | ANS, CANET, MCI, RIPE, RADB If there are two routes (with different origins) within one database, the changed date is used as a tiebreaker. Else, only database precedence is used. Thus, if the RADB entry has a more recent changed date than the RIPE, ANS will use the RIPE entry. | You should only have to register in one of the IRR component | databases. |19. How do I check what is registered in the IRR? The tool to use is whois. A few examples make the command self explanatory: whois -h whois.ra.net 128.228.0.0 whois -h whois.ripe.net as378 whois -h whois.canet.ca 142.77.0.0 20. Is there a tool to automatically create route filters based on IRR information? rlc is a route list compiler which is a subset of nlc/alc that allows the generation of route based filters (cisco access- lists) by extracting the nets belonging to an AS or AS MACRO from a routing database (i.e. Ripe Routing Database). In addition, it supports a limited set of functions to generate AS based filter lists. rlc is fully classless, and hence supports CIDR routes and subnets, as well as host routes. Source: ftp://dxcoms.cern.ch/pub/ripe-routing-wg Author: Jean-Michel Jouanigot, CERN <jimi(a)dxcoms.cern.ch> Contributors: Christian Panigl - Vienna University, Austria Bill Manning - ISI Tony Li - Cisco Systems Havard Eidnes - SINTEF, Norway Yakov Rekhter - Cisco Systems

1 0

Re: NANOG Meeting
by Sean Doran 20 Aug '95

20 Aug '95

>I think this is supposed to say Pittsburgh, PA. Ah, no, this is just the ultimate in address portability. Sean.

3 2

Comments on draft-ietf-cidrd-ownership-01.txt
by Dave Crocker 19 Aug '95

19 Aug '95

This note offers comments on the technical and operational aspects of the proposal for large-scale use of "address leasing" as proposed in: "On the Implications of Address Ownership for Internet Routing", I-D draft-ietf-cidrd-ownership-01.txt, by Rekhter & Li. The draft has been produced within the cidrd working group and is intended for publication as a Best Current Practises official IETF document. I'm copying the message to several lists due to: o the likely short general review that will be possible once the draft leaves the working group, o the types of concerns I raise in this note, o the likelihood of widespread impact from the proposal, and o the simultaneous discussion of related issues on those mailing lists, but I request that any discussion of my comments take place solely on the cidrd mailing list. Comments follow the document's section headings: 1 Abstract Paragraph 2 offers the document as a treatise or review of issues, citing a "focus" on one approach. The primary principle that the paper observes is that flat address spaces don't scale well. In fact the paper is simply a direct proposal for a particular scheme and should be characterized as such. It makes no effort to consider alternatives other than flat addressing nor even to consider the full impact of its recommended scheme. The title of the paper is not helpful and may well be misleading. It introduces the concept of address "leasing", rather than only discussing some drawbacks to permanent "ownership". Hence I suggest that the title of the paper be changed to something like "Proposal for General Use of Address Prefix Leasing". 2 Address allocation Paragraph 3 appears to claim that address ownership has not actually been the policy for more than 15 years and therefore implies that the idea of address leasing is not new and frankly experimental. This is at best incorrect and at worst misleading. For more than 15 years user sites have been given permanent network numbers and have been free to attach via any available provider using those numbers. It is only quite recently that providers have begun to require use of CIDR space and/or change addresses when changing providers. The paper should not attempt to suggest to the reader that leasing is anything other than a fundamental change in Internet address administration policy. As such, the paper should acknowledge and emphasize the frankly experimental nature of leasing done on a global scale. (Yes, I did say experimental. Contrary to the comments on the cidrd mailing list there has been no large scale use of a leasing policy and no real analysis of its effect. When claims are made to the contrary, they seem to hinge on a) the lack of changes needed for the large transit providers and their routers and b) a long history of organizations occasionally changing their IP network numbers, albeit mostly painfully. A side effect of this is that some other schemes which have been handily dismissed as experimental probably warrant more substantive consideration. One more presumption that warrants attention is that the Internet does not have time to consider alternatives. The facile counter to this concern is to ask whether the Internet has time to see CIDR and address leasing fail, eliminate local providers, or otherwise kill the Internet?) 3 Addressing and routing (no comments) 4 Address ownership Paragraph 4 refers to "space complexity" -- which I seems to mean the amount of space required -- for "the different schemes". Which schemes? The paper only discusses totally flat and totally hierarchical schemes. Is this total of 2 schemes what is being cited? In the next paragraph the paper states the importance of having an address reflect the topology of the network. Since the Internet is not a tree, but instead is a messy mesh one must ask by what procrustean process the Internet topology is to be represented by (relatively) stable hierarchical addresses? It is certainly true that a graph can be represented as a tree by taking a particular view of it but that representation only holds from that view. Such a view is applicable to snapshots needed when making routing decisions but not for globally-absolute addressing. The paper also says that changing an address is required as the network topology changes. This simply isn't true or, at least, is not what is being done or proposed. Internet topology changes all the time and sites are not required to change their addresses. At best this paragraph is seriously imprecise. At worst it is seriously wrong. The end effect is to aid in the myth of Internet topological hierarchy. We need to reverse this misleading view. The seventh paragraph discusses routing table exceptions. (The second sentence is awkward and should be re-written.) Exceptions are those entries which do not conform to the hierarchical model. The paragraph acknowledges that the Internet isn't strictly hierarchical but it then entirely misses the implication. For example it fails to note the effect of large-scale occurrence of multi-homing by local providers and users. (During discussions, the CIDR document has been referenced for its consideration of multi-homing. In fact that consideration clearly presumes that there IS a legitimate hierarchy in the Internet, which presumption no longer applies.) The last paragraph in the section makes quick mention of a possible impact on organizations which "sub-lease" numbers. This means that a local provider which changes transit providers will be forced to force its customers to renumber! While large transit providers well might not view this impact as substantial I suggest that it is, in fact, quite serious and deserves rather more discussion. For example CIDR and address leasing is likely to create a basic barrier to entry for local providers. ("Barrier to entry" is offered as a euphemism for "put all of them out of business.") They might not approve of such an effect. 5 Recommendations The first paragraph contains the disclaimer "Existing address assignments and allocations are outside the scope of this document." However the handling of existing addresses has very much been a part of working group discussions and appears to be very much a part of the intent behind pursuit of the address leasing model. In particular, working group discussions have cited CIDR as no longer being adequate when applied for new addresses only and that "recovering" existing addresses is required. Please note that I said "required". That, at least, is the message that has been communicated in recent working group discussions. If that message is wrong then we need to hear rather clearer explanations for the near-term need to promulgate a leasing policy. The proposal needs to attend to this issue directly and should not pretend that it is anything other than an immediate and pressing concern. The next-to-last paragraph acknowledges that users might incur some cost when renumbering, but the paragraph elides further discussion of the issue, instead simply saying that organizations need to consider tradeoffs. I suggest that a paper which is proposing a major change for the Internet is obligated to offer rather more detail about its impact and rather more concrete information for considering tradeoffs. It needs to list and discuss those tradeoffs. At the least that will demonstrate detailed understanding of the proposed policy's impact. The last paragraph cites DHCP. It appears to suggest that renumbering tools are a) adequate, and b) adequately deployed. The paper needs to discuss both of these assumptions in detail, particularly since there is a substantial constituency which believes that both assumptions are entirely incorrect. 6 Conclusions The first paragraph cites concerns for routing system scaling. However there is no concern expressed for Internet local providers or users. The paper needs substantial enhancement to consider the breadth of the proposal's effect. In fact I strongly urge than any proposal which attempts major change to the Internet -- as does this one -- be required to offer an operational "environmental impact statement." Equally strongly I suggest that this include a transition plan, as we require for other, equally massive changes. -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker(a)brandenburg.com

1 0

Re: CIDR FAQ
by Arnold Nipper 18 Aug '95

18 Aug '95

Hank Nussbacher wrote: > > On Thu, 17 Aug 1995 00:30:19 +0200 (MET DST) you said: > >Simon Poole wrote: > >> > >> Yakov, if you have data that CIDR is -not- working for new allocations > >> please present it here. > >> > >> Simon > > > >CIDR doesn't work as it should. We had to inject all of the more specifics > >of 194.45/16 cause Sprintlink isn't able to handle CIDR routes correctly. > > Can someone explain this a bit more? This sounds like a showstopper > for CIDR. > Xlink (AS517) was announcing 194.45.0.0/16 via Ebone. There are some networks within this block announced by PSI. Routing table at PSI looks like Mitch Levinn wrote: > > Hi there, > > >I've to second Mitch! Looks like a Sprint problem to me!! Mitch, would you be > >so kind to provide "show ip bgp 194.45.0.0 255.255.0.0 subnet" from the PSI > >box? Unfortunately neither Sprint nor Ebone NOC did anything (since Friday > >morning local time!) but ignoring the problem. I would really appreciate if > >EOT or Ebone NOC would try to fix this problem! > > Here's the output requested (from our MAE-East+ router): > > >show ip bgp 194.45.0.0 255.255.0.0 subnet > BGP table version is 1444840, local router ID is 192.41.177.245 > Status codes: s suppressed, * valid, > best, i - internal > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > *> 194.45.0.0 38.1.2.10 5 32768 i > *> 194.45.0.0/16 192.41.177.241 0 1239 1800 1755 517 ? > *> 194.45.1.0 38.1.2.10 5 32768 i > *> 194.45.2.0 38.1.2.10 5 32768 i > *> 194.45.3.0 38.1.2.10 5 32768 i > *> 194.45.4.0 38.1.2.10 5 32768 i > *> 194.45.5.0 38.1.2.10 5 32768 i > *> 194.45.6.0 38.1.2.10 5 32768 i > *> 194.45.7.0 38.1.2.10 5 32768 i > *> 194.45.16.0 192.41.177.181 0 3561 1220 ? > > This is just as it was last time the problem surfaced, I > believe. Subnets 0 through 7 are properly being announced through us, > subnet 16 goes to MCI, and the rest to Sprint. > > -Mitch > But Sprintlink was routing >traceroute -g c.psi.net 194.45.41.1 >traceroute to 194.45.41.1 (194.45.41.1), 30 hops max, 40 byte packets > 1 KarlSruhe.Core.xlink.net (193.141.40.252) 2 ms 5 ms > 2 muenchen.core.xlink.net (192.54.104.241) 18 ms 10 ms > 3 Munich-EBS.EBONE.NET (192.121.158.13) 12 ms 13 ms > 4 icm-dc-1-S2/5-1984k.icp.net (198.67.129.17) 210 ms 141 ms > 5 icm-mae-e-H1/0-T3.icp.net (198.67.131.9) 310 ms 253 ms > 6 mae-east.psi.net (192.41.177.245) 254 ms 266 ms > 7 c.psi.net (192.33.4.12) 257 ms 289 ms > 8 192.33.4.1 (192.33.4.1) 227 ms 257 ms > 9 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 245 ms 250 ms >10 mae-east.psi.net (192.41.177.245) 203 ms 228 ms >11 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 215 ms 193 ms TT to Sprintlink didn't help. After 4 days still no response. I've fixed this silly routing by announcing all more specifics. > > > >Arnold > > Hank Arnold

2 2

Re: CIDR FAQ
by Hank Nussbacher 18 Aug '95

18 Aug '95

On Thu, 17 Aug 1995 14:57:40 -0700 (PDT) you said: >> >Does that mean that all the internet registries no longer allocate >> >/24 (or longer) prefixes that have nothing to do with the actual >> >Internet topology (these prefixes aka "portable addresses") ? Perhaps >> >folks from various Internet registries would be able to answer this >> >question. >> >> I assign /22s to ISPs. When they use them up I give them another /22. >> Private companies that show a need for a /24 are assigned a /24. >> > >Ah. here is the rub. When you ISP buddies come back, you should ask >them to return the origianal /22 for a /20. That way, the total size >of the routing system stays the same! Great idea. Know ANYONE who does that? The best I can do is give them a /20 (in addition to the original /22) if their growth warrants it. > >-- >--bill Hank

3 2