From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1482.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc1482.txt (limited to 'doc/rfc/rfc1482.txt') diff --git a/doc/rfc/rfc1482.txt b/doc/rfc/rfc1482.txt new file mode 100644 index 0000000..57e1ff1 --- /dev/null +++ b/doc/rfc/rfc1482.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group Mark Knopper +Request for Comments: 1482 Steven J. Richardson + Merit/NSFNET + June 1993 + + Aggregation Support in the NSFNET Policy-Based Routing Database + +Status of this memo + + This memo provides information for the Internet community. It does + not specify an Internet standard. Distribution of this memo is + unlimited. + +Abstract + + This document describes plans for support of route aggregation, as + specified in the descriptions of Classless Inter-Domain Routing + (CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone Network + Service. Mechanisms for exchange of route aggregates between the + backbone service and regional/midlevel networks are specified. + Additionally, the memo proposes the implementation of an Aggregate + Registry which can be used by network service providers to share + information about the use of aggregation. Finally, the operational + impact of incorporating CIDR and aggregation is considered, including + an analysis of how routing table size will be affected. This impact + analysis will be used to modify the deployment plan, if necessary, to + maximize operational stability. + +1. Introduction + + The Internet network service provider community and router vendors + (as well as the IESG and various IETF working groups) have agreed + that the time for deployment of route aggregation is upon us. This + topic has been discussed in the BGP-D, NJM and ORAD working groups at + several IETF meetings; it was a discussion topic of the NSFNET + Regional Techs' Meetings in January and June, 1993; and it was also a + topic of several meetings of the Federal Engineering Planning Group + and Engineering and Operations Working Group of the Federal Network + Council. + + All have generally agreed that Summer, 1993 is the time to enable + BGP-4 and CIDR aggregation. Each of the parties is responsible for + its own aspect of CIDR implementation and practice. This memo + describes Merit's plans for support of route aggregation on the + NSFNET, and a proposal for implementing a database of aggregation + information for use by network providers. + + + + + +Knopper & Richardson [Page 1] + +RFC 1482 Routing Aggregation Support July 1993 + + +2. Aggregation Support by the Backbone Service + + The NSFNET backbone service includes a Policy-Based Routing Database + system which currently holds the set of network numbers that are + accepted by the backbone service with a list of Autonomous System + numbers from which announcements of these network numbers are + expected. In order to implement CIDR, the database system will be + modified to allow aggregation of routing information to be + configured. + + The NSFNET will (initially) not support de-aggregation on its + outbound announcements. See section 2.3. + +2.1 Current Configuration Capabilities + +2.1.1 Inbound Announcements + + An example of the way a network number is currently configured is as + follows: + + 35 1:237 2:233 3:183 4:266 5:267 6:1225 + + This shows that network number 35 (ie. 35.0.0.0, a class A net + number) is configured on the T3 backbone such that routing + announcements are expected from up to 6 autonomous systems. The + primary path is via AS 237, secondary is via AS 233, etc. + +2.1.2 Outbound Announcements + + Currently the NSFNET database has a list of AS's or network numbers + for each neighbor AS that are announced by the backbone to that AS. + These announcements are specified currently by "announcetoAS" + statements--which implement policies submitted by midlevels to + Merit--and then included in the ANSnet router configuration files. + There are two forms of these statements. The first form uses the + "norestrict" clause and indicates that all of the network numbers + within each AS in the list should be announced to the neighbor + midlevel AS. For example: + + announcetoAS 42 norestrict ASlist 22 26 38 60 68 + + In this example, the NSFNET is configured to announce to neighboring + midlevel AS 42, all networks in the routing table that were announced + from AS's 22, 26, 38, 60 and 68. + + If the "norestrict" keyword is changed to "restrict", this indicates + that an explicit announce list of network numbers for the AS is + specified in the configuration file. The NSFNET will only announce + + + +Knopper & Richardson [Page 2] + +RFC 1482 Routing Aggregation Support July 1993 + + + network numbers that were announced by the AS's in the list, *AND* + which appear in the "restrict list" of network numbers submitted + separately by the midlevel. + + For example, + + announcetoAS 42 restrict ASlist 22 + + announce 192.135.237 + + These statements mean that AS 42 only wishes to hear announcements + from the backbone about the nets in AS 22 which are explicitly listed + here (i.e., net 192.135.237). + + It is also possible, when using the "restrict" keyword, to list + specific "noannounce" lines. Those indicate that all of the networks + listed in the routing table for the AS should be announced except + those listed on the noannounce clauses. (There is also a + "noannouncetoAS" statement[4].) + +2.2 New Configuration Features for Aggregation + + There will be three new capabilities for which the backbone service + can be configured to support aggregation. The first two allow + aggregates to be accepted and stored in the backbone routing tables + based on announcements by the regional network (autonomous system or + AS) peers. The third allows the announcement of aggregates to the AS + neighbor peers. The following sections give examples of the three + features. + + We use the notation to describe an aggregate. + This refers to the IP prefix "net-IP", with a mask which has + "prefix-length" 1's as counted from the high-order end. For example, + <192.64.128 17> is equivalent to <192.64.128, 255.255.128.0> [5]. + (The form using prefix-length rather than the mask is more compact.) + +2.2.1 NSFNET accepts aggregates + + In this case the regional peer router is CIDR-capable (i.e., runs + BGP-4) and the announcement comes into the backbone as an IP address + prefix. + + To illustrate this in the spirit of sec. 2.1.1: + + <192.64.128 17> 1:189 2:24 3:267 + + In this example, independent of the "class" of IP network number, an + aggregate containing network addresses matching a pattern in which + + + +Knopper & Richardson [Page 3] + +RFC 1482 Routing Aggregation Support July 1993 + + + the first 17 bits match the prefix 192.64.128 will be accepted in + announcements to the NSFNET service. The primary path to + destinations covered by the prefix is expected via AS 189, the + secondary, via AS 24, etc. + +2.2.2 NSFNET aggregates by proxy + + The other method of incorporating CIDR aggregate announcements into + the backbone routing tables is that of aggregation by proxy. In this + case, the backbone is configured to perform aggregation on behalf of + a peer AS which is not configured to announce the aggregate to the + backbone (i.e., an AS which does not connect to the backbone via a + CIDR-capable peer). + + An example of this aggregation technique is: + + proxy <192.64.128 17> 1:189 2:24 3:267 + if <192.64.192 24> + or <192.64.129 24> + or <192.64.167 24> + + (Note: the syntax used in this document is arbitrary and is only used + to illustrate the method. The syntax to be used in actual routing + requests is to be determined.) + + In this example, the aggregate <192.64.128 17> will be stored and + propagated within the backbone as an aggregate under a set of + conditions. Initially, the GateD support will allow an "OR" list of + conditions such that if one of the aggregates in the list matches the + proxy aggregate will be stored[6]. For the case above, this means + that, if any of the CIDR aggregates: + + <192.64.192 24> + <192.64.129 24> + <192.64.167 24> + + (which--under the current, class-based IP address system--are + equivalent to the class C net numbers 192.64.192, 192.64.129, or + 192.64.167, respectively) is heard, the backbone router will act as + though it heard the announcement of the single CIDR aggregate + <192.64.128 17>. + +2.2.3 NSFNET announces aggregates + + The functionality of the current system, as outlined in sec. 2.1.2, + above, will continue to exist once CIDR is implemented. The + "norestrict" function (or its equivalent in the new software) will + specify that all network reachability information received from a set + + + +Knopper & Richardson [Page 4] + +RFC 1482 Routing Aggregation Support July 1993 + + + of Autonomous Systems, including any aggregates, will be announced. + It should also be possible to use to the equivalents of the + "restrict" keyword and the "announce" (or "noannounce") statement in + order to limit the announcements of the aggregations within an AS to + any desired subset. + +2.3 Specifically Unsupported Capabilities, Limits of Initial Deployment + + There are some aspects of aggregation which will specifically not be + supported in the initial deployment of CIDR capabilities on the + NSFNET backbone. In particular, when the NSFNET service announces + routes to midlevel peers, de-aggregation will not be performed [3]. + Therefore, a peer which needs to receive full routing information + should run a protocol which supports CIDR (initially, BGP-4; later, + IDRP). Peer networks using default routing will be able to reach + networks that are part of aggregated routing information across the + backbone (as in section 6.4 of [3]). + +3. CIDR Aggregate Registry + + In discussions with network service providers, it has become apparent + that there is a great need for sharing of aggregate information; this + is necessary to fulfill the coordination referred to in sec. 2.3. + Beyond the need to implement CIDR aggregation facilities in the + NSFNET Policy-Based Routing Database (as described in section 2), + there is a clear need to have a separate database which will allow + aggregate information from any Autonomous System to be stored and + made available for easy electronic retrieval. This information can be + used for routing coordination and policy configuration in the larger, + non-NSFNET-centric, inter-domain context. + + One of the expected uses of such a database is to help determine, as + CIDR matures, the granularity of aggregation of network reachability + information with respect to policy. The useful scope of aggregation + is the subject of much discussion[5][7], and will be influenced by + such considerations as how network number allocation has been + handled, and whether the network provider has renumbered its client + networks to conform to CIDR aggregation boundaries. Rules and issues + regarding network number allocation with CIDR are discussed in [8] + and [7]. + + In order further these goals, Merit proposes to implement a "CIDR + Aggregate Registry" to provide sharing of aggregate information for + the Internet inter-domain routing community. Initially, this will be + a simple database without much structure. It is not intended to hold + only aggregates which are announced or accepted by the NSFNET + service; rather, it should be a community registry that all will be + invited to use and make use of. + + + +Knopper & Richardson [Page 5] + +RFC 1482 Routing Aggregation Support July 1993 + + + The Aggregate Registry will consist of a list of aggregate + announcement statements. Each statement consists of four types of + information, along with contact information: + + 1) CIDR Aggregate: The aggregate identifier, consisting of a + network number prefix and the prefix length. For example, + <192.29.128 16>. + + 2) Home AS: The source AS number for the aggregate. That is, the + AS number of the network service provider that initially + aggregates the network reachability information into the aggregate + for announcement to its neighbors. + + 3a) Announcing AS: An AS number that announces this aggregate to + its neighbor AS's. + + 3b) Neighbor AS list: A list of neighbor AS's to whom the + aggregate will be announced by the AS named in 3a. + + 4) Contact information: eg. e-mail address and name or NIC handle + of the administrative and technical contacts for the source AS. + + Thus, a given aggregate is listed once as announced by its source AS. + It may then be listed once again per transit AS which announces the + aggregate downstream to its neighbors. For example, the CIDR + aggregate <199.29.128 16> could be listed as: + + CIDR aggregate home ann neighbor + (prefix-length) AS AS AS list contacts + ----------------------------------------------------------- + <199.29.128 16> 100 100 200 201 690 fred@nowhere.net + <199.29.128 16> 100 690 266 267 1225... + <199.29.128 16> 100 200 297 372 + <199.29.128 16> 100 201 771 1262 + + Note: This can be represented using the syntax used for objects + in the RIPE-81 paper[9]. + + Here, AS 100 (the source AS) performs any aggregation and announces + the CIDR aggregate <199.29.128 16> to neighbor ASs 200, 201, and 690. + In turn, AS 200 announces this same aggregate to its neighbor ASs 297 + and 372; further lines show announcements of the given aggregate by + AS 690 and AS 201. + + Note that this registry reflects both the simple list of aggregates + that are supported by the union of network providers, as well as + information on inter-domain topology for the Internet. Merit will + implement procedures for registering any network provider's + + + +Knopper & Richardson [Page 6] + +RFC 1482 Routing Aggregation Support July 1993 + + + aggregates in the Registry; for those CIDR aggregates carried over + the NSFNET backbone, Merit will implement procedures for integrating + this Registry with the process of updating the aggregate routing + announcements. Requests to update the information will be handled + via e-mail or on-line registration tools. + +4. Effects of CIDR on Operational Aspects of the Internet + + The introduction of CIDR will clearly necessitate various changes + beyond the introduction of new router software. In particular, Merit + and other network service providers will have to adjust tools, + reports, and procedures as CIDR is implemented and evolved, and these + changes will have to be coordinated in order to ensure a smooth + transition to the CIDR-capable Internet. + + While this document is by no means exhaustive, some of the areas + affected are discussed briefly below; what is intended is to foster + an awareness of some these changes, so as to initiate thinking about + and planning for this transition. While it is obvious that CIDR and + policy routing imply greater coordination of many operational + matters, it is not clear how profoundly this will affect the day-to- + day running of the Internet. + + (Note: Aspects of the actual phased deployement of CIDR are covered + in [3] and [10].) + +4.1 NSFNET Configuration Files and Reports; Neighbor AS Configurations + + The addition of CIDR capability to the NSFNET Policy-Based Routing + Database, as outlined in sec. 2, will require the updating of at + least the following reports which are currently produced by Merit + (and available via anonymous FTP from nic.merit.edu): + + ans_core.now as-site.now country.now net-comp.now net-net.now + net-ter.now non-us.now + + Any tools which access this information, such as the various clients + or scripts released by Merit or developed by others, will have to be + changed. + + However, the most striking change will be in the transition from + rcp_routed to GateD; it is very different in important particulars, + and follows different conceptual principles [11]. + + Network providers which develop any part of their configuration files + from parsing the NSFNET configuration files or reports *MUST* plan + for these changes in order to help themselves and the Internet + community achieve a smooth transition to CIDR. + + + +Knopper & Richardson [Page 7] + +RFC 1482 Routing Aggregation Support July 1993 + + +4.2 Routing and Administrative Policies + + In this document, Merit has stated its commitment to supporting CIDR + through both changing policies related to administering the NSFNET + and developing a CIDR Aggregate Registry for the broader Internet + community. + + In addition to these changes, here are some of the other policies, + administrative and routing, which must to be coodinated in order to + achieve optimum benefits of CIDR: + + - policies of the InterNIC and of network service providers in + assigning (CIDR) IP nets and blocks, as mentioned above; + + - policies of the various ASs in coordination of transit and other + routing policies; + + - policies of registration of new networks, from the InterNIC or + network provider, through the CIDR Aggregate Registry, etc.; + + - policies related to coordination of routing changes; + + - coordination of routing policies, in general, to avoid new + classes of routing problems due to new methods of routing. + +4.3 Realtime Issues + + Issues which have not been examined in detail are: + + - debugging of routing/connectivity problems; + + - stability and other properties of routing under various + scenarios of CIDR configuration and network topology; + + - explicit specification of routing decision algorithms to avoid + routing anomalies; + + - increased network load due to packets traversing an AS, such as + the NSFNET backbone, before being discarded due to addressing a + "hole" in a CIDR aggregate. + +4.4 Estimate of Reductions in Routing Tables + + An argument in favor of the implementation CIDR is the effect which + it should have upon the NSFNET and other routing tables [1] [5]. The + burning question is: What is the magnitude of this effect? In view + of the various issues to be dealt with, this is an important + consideration. + + + +Knopper & Richardson [Page 8] + +RFC 1482 Routing Aggregation Support July 1993 + + + In terms of the immediate savings in reduction of the NSFNET backbone + routing tables, if a set of aggregates were done all at once, a + recent calculation--which might be characterized as an optimistic + estimate using a pessimistic algorithm (it looks for the longest + continuous block of addresses announced to the NSFNET backbone)-- + yields [12]: + + 861 size 2 saving 861 announcements + 286 size 4 saving 858 announcements + 117 size 8 saving 819 announcements + 67 size 16 saving 1005 announcements + 13 size 32 saving 403 announcements + 3 size 64 saving 189 announcements + 1347 total saving 4135 announcements of 12348 (33%). + + Here, the first column represents the number of CIDR aggregates of + the given "size," and shows the corresponding reduction in net + announcements due to the adoption of this aggregate. (A CIDR + aggregate of "size " is one which encompasses class A, B, or C + networks; the 67 "size 16" CIDR aggregates actually combine + announcements for 16 separate networks into a single net aggregate.) + It is unclear, at this time, whether or not the true savings would be + of this magnitude, but the extended report provides a basis for + discussion [12]. + + The other aspect of impact upon the routing tables, the reduction in + the rate of growth (and the concomitant slowing of the rate of + exhaustion of IP address space), is an entirely different matter. + Simple calculations related to the rate of class B address space + exhaustion indicate that CIDR-conformant policies of the InterNIC + with respect to address assignment is helping [1]. + + Clearly, more detailed analysis is desirable in order to better + understand the realistic gains of the CIDR deployment process, both + initially and in the longer term. + +5. Conclusions and Next Steps + + Implementation of CIDR is underway, but there is still a fair amount + of planning and discussion that is needed for a successful + transition. Merit is proposing specific functions for CIDR + aggregation that will be supported by the NSFNET, as well as a CIDR + Aggregate Registry that can serve as the basis for inter-domain + routing coordination. + + The Aggregate Registry will allow a set of tools to be developed that + can facilitate the design of aggregation policy. A query tool to + allow lookup of aggregation information for a given network or + + + +Knopper & Richardson [Page 9] + +RFC 1482 Routing Aggregation Support July 1993 + + + aggregate would be very useful. Additional database functionality + will also be desired for more powerful queries. It is specifically a + goal to work with RIPE to make sure that the Merit and RIPE database + approaches are compatible and allow interworking of tools. An AS + topology database would be most useful in routing policy + determination and coordination as well. + + In addition to these areas, many other issues require further work in + order to develop the operational framework necessary for the + successful use of CIDR on the Internet. It is critical that the + deployment of CIDR and related tools to preserve address and routing + table space must not compromise the operational stability of the + NSFNET and the wider Internet. + +6. Security Considerations + + Security issues are not discussed in this document. + +7. Acknowledgements + + The authors would like to acknowledge the following persons, whose + comments and discussions have helped to shape this document: + + Dennis Ferguson, Advanced Network and Services, Inc. + Jeffrey Honig, Cornell University + William Manning, Rice University/SESQUINET + The Merit Internet Engineering and Network Management + Systems groups. + +8. Authors' Addresses + + Knopper, Mark A. + Merit Network, Inc. + 1071 Beal Ave. + Ann Arbor, MI 48109-2103 + + e-mail: mak@merit.edu + phone: (313) 763-6061 + fax: (313) 747-3745 + + Richardson, Steven J. + Merit Network, Inc. + 1071 Beal Ave. + Ann Arbor, MI 48109-2103 + + e-mail: sjr@merit.edu + phone: (313) 747-4813 + fax: (313) 747-3745 + + + +Knopper & Richardson [Page 10] + +RFC 1482 Routing Aggregation Support July 1993 + + +9. References + + [1] Fuller, V., Li, T., Yu, J., and Varadhan, K., "Supernetting: an + Address Assignment and Aggregation Strategy", RFC1338, Update, + Work in Progress, June 1992. + + [2] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4", Work In + Progress, April 1993. + + [3] Topolcic, C., "Notes of BGP-4/CIDR Coordination Meeting of 11 + March 93", Work in Progress, March 1993. + + [4] Villamizer, C., in a document describing rcp_routed.conf options + and syntax, May, 1993. + + [5] Syntax used in Ford, P., Rekhter, Y., Braun, H-W., "Improving + the Routing and Addressing of IP", IEEE Network, pp. 10-15, May + 1993. + + [6] Ferguson, D., private correspondence, March, 1993. + + [7] Rekhter, Y., and Li, T., "An Architecture for IP Address + Allocation with CIDR", Work in Progress, February, 1993. + + [8] Gerich, E., "Guidelines for Management of IP Address Space", + RFC1466, May 1993. + + [9] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P., and + Terpstra, M., "Representation of IP Routing Policies in the RIPE + Database" (ripe-81), Work in Progress, February, 1993. + + [10] Rekhter, Y., and Topolcic, C., "Exchanging Routing Information + Across Provider/Subscriber Boundaries in the CIDR Environment", + Work in Progress, April 1993. + + [11] Fedor, M., Honig, J., Coltun, R., Ferguson, D., "gated- + config(5)" manpage, from the "gated-R3_0Beta_2" distribution, 7 + October 1992. + + [12] Johnson, D., analysis available via anonymous FTP from + merit.edu:/pub/nsfnet/cidr/auto-aggregates, June 1993. + + [13] Topolcic, C., "Schedule for IP Address Space Management + Guidelines", RFC1367, October, 1993. + + + + + + + +Knopper & Richardson [Page 11] + \ No newline at end of file -- cgit v1.2.3