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/rfc1786.txt | 4651 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 4651 insertions(+) create mode 100644 doc/rfc/rfc1786.txt (limited to 'doc/rfc/rfc1786.txt') diff --git a/doc/rfc/rfc1786.txt b/doc/rfc/rfc1786.txt new file mode 100644 index 0000000..5f084e9 --- /dev/null +++ b/doc/rfc/rfc1786.txt @@ -0,0 +1,4651 @@ + + + + + + +Network Working Group T. Bates +Request for Comments: 1786 MCI Telecommunications Corporation +Category: Informational E. Gerich + Merit, Inc. + L. Joncheray + Merit, Inc. + J-M. Jouanigot + CERN + D. Karrenberg + RIPE NCC + M. Terpstra + Bay Networks, Inc. + J. Yu + Merit, Inc. + March 1995 + + + Representation of IP Routing Policies + in a Routing Registry + (ripe-81++) + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document was originally published as a RIPE document known as + ripe-181 but is also being published as an Informational RFC to reach + a larger audience than its original scope. It has received community + wide interest and acknowledgment throughout the Internet service + provider community and will be used as the basic starting point for + future work on Internet Routing Registries and routing policy + representation. It can also be referred to as ripe-81++. This + document is an update to the original `ripe-81'[1] proposal for + representing and storing routing polices within the RIPE database. It + incorporates several extensions proposed by Merit Inc.[2] and gives + details of a generalized IP routing policy representation to be used + by all Internet routing registries. It acts as both tutorial and + provides details of database objects and attributes that use and make + up a routing registry. + + + + + + + + +Bates, et al. [Page 1] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + + + Table of Contents + + + + + 1. Introduction ................................................ 3 + + 2. Organization of this Document ............................... 3 + + 3. General Representation of Policy Information ............... 5 + + 4. The Routing Registry and the RIPE Database .................. 11 + + 5. The Route Object ............................................ 16 + + 6. The Autonomous System Object ................................ 26 + + 7. AS Macros ................................................... 36 + + 8. The Community Object ........................................ 38 + + 9. Representation of Routing Policies .......................... 41 + + 10. Future Extensions .......................................... 50 + + 11. References ................................................. 51 + + 12. Security Considerations .................................... 52 + + 13. Authors' Addresses ......................................... 53 + + Appendix A - Syntax for the "aut-num" object ................... 55 + + Appendix B - Syntax for the "community" object ................. 68 + + Appendix C - Syntax for the "as-macro" object .................. 72 + + Appendix D - Syntax for the "route" object ..................... 76 + + Appendix E - List of reserved words ............................ 80 + + Appendix F - Motivations for RIPE-81++ ......................... 81 + + Appendix G - Transition strategy ............................... 83 + + + + +Bates, et al. [Page 2] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +1. Introduction + + This document is a much revised version of the RIPE routing registry + document known as ripe-81 [1]. Since its inception in February, 1993 + and the establishment of the RIPE routing registry, several additions + and clarifications have come to light which can be better presented + in a single updated document rather than separate addenda. + + Some of the text remains the same the as the original ripe-81 + document keeping its tutorial style mixed with details of the RIPE + database objects relating to routing policy representation. However + this document does not repeat the background and historical remarks + in ripe-81. For these please refer to the original document. It + should be noted that whilst this document specifically references the + RIPE database and the RIPE routing registry one can easily read + "Regional routing registry" in place of RIPE as this representation + is certainly general and flexible enough to be used outside of the + RIPE community incorporating many ideas and features from other + routing registries in this update. + + This document was originally published as a RIPE document known as + ripe-181 but is also being published as an Informational RFC to reach + a larger audience than its original scope. It has received large + interest and acknowledgment within the Internet service provider + community and will be used as the basic starting point for future + work on Internet Routing Registries and routing policy + representation. It but can also be referred to as ripe-81++. + + We would like to acknowledge many people for help with this document. + Specifically, Peter Lothberg who was a co-author of the original + ripe-81 document for his many ideas as well as Gilles Farrache, + Harvard Eidnes, Dale Johnson, Kannan Varadhan and Cengiz Alaettinoglu + who all provided valuable input. We would also like to thank the + RIPE routing working group for their review and comment. Finally, we + like to thank Merit Inc. for many constructive comments and ideas and + making the routing registry a worldwide Internet service. We would + also like to acknowledge the funding provided by the PRIDE project + run in conjunction with the RARE Technical Program, RIPE and the RIPE + NCC without which this paper would not have been possible. + +2. Organization of this Document + + This document acts as both a basic tutorial for understanding routing + policy and provides details of objects and attributes used within an + Internet routing registry to store routing policies. Section 3 + describes general issues about IP routing policies and their + representation in routing registries. Experienced readers may wish to + skip this section. Section 4 provides an overview of the RIPE + + + +Bates, et al. [Page 3] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + database, its basic concepts, schema and objects which make up the + database itself. It highlights the way in which the RIPE database + splits routing information from allocation information. Sections 5, + 6, 7 and 8 detail all the objects associated with routing policy + representation. Section 9 gives a fairly extensive "walk through" of + how these objects are used for expressing routing policy and the + general principles behind their use. Section 10 provides a list of + references used throughout this document. Appendix A, B, C and D + document the formal syntax for the database objects and attributes. + Appendix F details the main changes from ripe-81 and motivations for + these changes. Appendix G tackles the issues of transition from + ripe-81 to ripe-81++. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 4] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +3. General Representation of Policy Information + + Networks, Network Operators and Autonomous Systems + + Throughout this document an effort is made to be consistent with + terms so as not to confuse the reader. + + When we talk about "networks" we mean physical networks which have a + unique classless IP network number: Layer 3 entities. We do not mean + organizations. + + We call the organizations operating networks "network operators". + For the sake of the examples we divide network operators into two + categories: "service providers" and "customers". A "service provider" + is a network operator who operates a network to provide Internet + services to different organizations, its "customers". The + distinction between service providers and customers is not clear cut. + A national research networking organization frequently acts as a + service provider to Universities and other academic organizations, + but in most cases it buys international connectivity from another + service provider. A University networking department is a customer of + the research networking organization but in turn may regard + University departments as its customers. + + An Autonomous System (AS) is a group of IP networks having a single + clearly defined routing policy which is run by one or more network + operators. Inside ASes IP packets are routed using one or more + Interior Routing Protocols (IGPs). In most cases interior routing + decisions are based on metrics derived from technical parameters like + topology, link speeds and load. The entity we refer to as an AS is + frequently and more generally called a routing domain with the AS + just being an implementation vehicle. We have decided to use the term + AS exclusively because it relates more directly with the database + objects and routing tools. By using only one term we hope to reduce + the number of concepts and to avoid confusion. The academically + inclined reader may forgive us. + + ASes exchange routing information with other ASes using Exterior + Routing Protocols (EGPs). Exterior routing decisions are frequently + based on policy based rules rather than purely on technical + parameters. Tools are needed to configure complex policies and to + communicate those policies between ASes while still ensuring proper + operation of the Internet as a whole. Some EGPs like BGP-3 [8] and + BGP-4 [9] provide tools to filter routing information according to + policy rules and more. None of them provides a mechanism to publish + or communicate the policies themselves. Yet this is critical for + operational coordination and fault isolation among network operators + and thus for the operation of the global Internet as a whole. This + + + +Bates, et al. [Page 5] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + document describes a "Routing Registry" providing this functionality. + + Routing Policies + + The exchange of routing information between ASes is subject to + routing policies. Consider the case of two ASes, X and Y exchanging + routing information: + + + NET1 ...... ASX <---> ASY ....... NET2 + + + ASX knows how to reach a network called NET1. It does not matter + whether NET1 is belonging to ASX or some other AS which exchanges + routing information with ASX either directly or indirectly; we just + assume that ASX knows how to direct packets towards NET1. Likewise + ASY knows how to reach NET2. + + In order for traffic from NET2 to NET1 to flow between ASX and ASY, + ASX has to announce NET1 to ASY using an external routing protocol. + This states that ASX is willing to accept traffic directed to NET1 + from ASY. Policy thus comes into play first in the decision of ASX to + announce NET1 to ASY. + + In addition ASY has to accept this routing information and use it. + It is ASY's privilege to either use or disregard the information that + ASX is willing to accept traffic for NET1. ASY might decide not to + use this information if it does not want to send traffic to NET1 at + all or if it considers another route more appropriate to reach NET1. + + So in order for traffic in the direction of NET1 to flow between ASX + and ASY, ASX must announce it to ASY and ASY must accept it from ASX: + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 6] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + resulting packet flow towards NET1 + <<=================================== + | + | + announce NET1 | accept NET1 + --------------> + -------------> + | + AS X | AS Y + | + <------------- + <-------------- + accept NET2 | announce NET2 + | + | + resulting packet flow towards NET2 + ===================================>> + + + Ideally, and seldom practically, the announcement and acceptance + policies of ASX and ASY are identical. + + In order for traffic towards NET2 to flow, announcement and + acceptance of NET2 must be in place the other way round. For almost + all applications connectivity in just one direction is not useful at + all. + + Usually policies are not configured for each network separately but + for groups of networks. In practise these groups are almost always + defined by the networks forming one or more ASes. + + + + Routing Policy limitations + + It is important to realize that with current destination based + forwarding technology routing policies must eventually be expressed + in these terms. It is relatively easy to formulate reasonable + policies in very general terms which CANNOT be expressed in terms of + announcing and accepting networks. With current technology such + policies are almost always impossible to implement. + + + The generic example of a reasonable but un-implementable routing is a + split of already joined packet streams based on something other than + destination address. Once traffic for the same destination network + passes the same router, or the same AS at our level of abstraction, + it will take exactly the same route to the destination (disregarding + special cases like "type of service" routing, load sharing and + + + +Bates, et al. [Page 7] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + routing instabilities). + + In a concrete example AS Z might be connected to the outside world by + two links. AS Z wishes to reserve these links for different kinds of + traffic, let's call them black and white traffic. For this purpose + the management of AS Z keeps two lists of ASes, the black and the + white list. Together these lists comprise all ASes in the world + reachable from AS Z. + + "W" + <---> + ... AS Z .... NET 3 + <---> + "B" + + It is quite possible to implement the policy for traffic originating + in AS Z: AS Z will only accept announcements for networks in white + ASes on the white link and will only accept announcements for + networks in black ASes on the black link. This causes traffic from + networks within AS Z towards white ASes to use the white link and + likewise traffic for black ASes to use the black link. + + Note that this way of implementing things makes it necessary to + decide on the colour of each new AS which appears before traffic can + be sent to it from AS Z. A way around this would be to accept only + white announcements via the white link and to accept all but white + announcements on the black link. That way traffic from new ASes + would automatically be sent down the black link and AS Z management + would only need to keep the list of white ASes rather than two lists. + + Now for the unimplementable part of the policy. This concerns + traffic towards AS Z. Consider the following topology: + + B AS ---) "W" + W AS ---) ---> + B AS ---)>> AS A ---> ... AS Z .... NET 3 + B AS ---) ---> + W AS ---) "B" + + As seen from AS Z there are both black and white ASes "behind" AS A. + Since ASes can make routing decisions based on destination only, AS A + and all ASes between AS A and the two links connecting AS Z can only + make the same decision for traffic directed at a network in AS Z, say + NET 3. This means that traffic from both black and white ASes + towards NET 3 will follow the same route once it passes through AS A. + This will either be the black or the white route depending on the + routing policies of AS A and all ASes between it and AS Z. + + + + +Bates, et al. [Page 8] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + The important thing to note is that unless routing and forwarding + decisions can be made based on both source and destination addresses, + policies like the "black and white" example cannot be implemented in + general because "once joined means joined forever". + + + Access Policies + + Access policies contrary to routing policies are not necessarily + defined in terms of ASes. The very simplest type of access policy is + to block packets from a specific network S from being forwarded to + another network D. A common example is when some inappropriate use of + resources on network D has been made from network S and the problem + has not been resolved yet. Other examples of access policies might be + resources only accessible to networks belonging to a particular + disciplinary group or community of interest. While most of these + policies are better implemented at the host or application level, + network level access policies do exist and are a source of + connectivity problems which are sometimes hard to diagnose. Therefore + they should also be documented in the routing registry according to + similar requirements as outlined above. + + + + Routing vs. Allocation information + + The RIPE database contains both routing registry and address space + allocation registry information. In the past the database schema + combined this information. Because RIPE was tasked with running both + an allocation and routing registry it seemed natural to initially + combine these functions. However, experience has shown that a clear + separation of routing information from allocation is desirable. Often + the maintainer of the routing information is not the same as the + maintainer of the allocation information. Moreover, in other parts + of the world there are different registries for each kind of + information. + + Whilst the actual routing policy objects will be introduced in the + next section it is worthy of note that a transition from the current + objects will be required. Appendix G details the basic steps of such + a transition. + + This split in information represents a significant change in the + representational model of the RIPE database. Appendix F expands on + the reasons for this a little more. + + + + + + +Bates, et al. [Page 9] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Tools + + The network operators will need a series of tools for policy routing. + Some tools are already available to perform some of the tasks. Most + notably, the PRIDE tools [3] from the PRIDE project started in + September 1993 as well as others produced by Merit Inc [4] and CERN + [5]. + + These tools will enable them to use the routing policy stored in the + RIPE routing registry to perform such tasks as check actual routing + against policies defined, ensure consistency of policies set by + different operators, and simulate the effects of policy changes. + + Work continues on producing more useful tools to service the Internet + community. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 10] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +4. The Routing Registry and the RIPE Database + + One of the activities of RIPE is to maintain a database of European + IP networks, DNS domains and their contact persons along with various + other kinds of network management information. The database content + is public and can be queried using the whois protocol as well as + retrieved as a whole. This supports NICs/NOCs all over Europe and + beyond to perform their respective tasks. + + The RIPE database combines both allocation registry and routing + registry functions. The RIPE allocation registry contains data about + address space allocated to specific enterprises and/or delegated to + local registries as well as data about the domain name space. The + allocation registry is described in separate documents [6,7] and + outside the scope of this document. + + + Database Objects + + Each object in the database describes a single entity in the real + world. This basic principle means that information about that + entity should only be represented in the corresponding + database object and not be repeated in other objects. The whois + service can automatically display referenced objects where + appropriate. + + The types of objects stored in the RIPE database are summarized in + the table below: + + + R Object Describes References + ____________________________________________________________________ + + B person contact persons + + A inetnum IP address space person + A domain DNS domain person + + R aut-num autonomous system person + (aut-num,community) + R as-macro a group of autonomous systems person, aut-num + R community community person + R route a route being announced aut-num, community + + R clns CLNS address space and routing person + + + The first column indicates whether the object is part of the + allocation registry (A), the routing registry (R) or both (B). The + + +Bates, et al. [Page 11] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + last column indicates the types of objects referenced by the + particular type of object. It can be seen that almost all objects + reference contact persons. + + Objects are described by attributes value pairs, one per line. + Objects are separated by empty lines. An attribute that consists of + multiple lines should have the attribute name repeated on + consecutive lines. The information stored about network 192.87.45.0 + consists of three objects, one inetnum object and two person + objects and looks like this: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 12] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + inetnum: 192.87.45.0 + netname: RIPE-NCC + descr: RIPE Network Coordination Centre + descr: Amsterdam, Netherlands + country: NL + admin-c: Daniel Karrenberg + tech-c: Marten Terpstra + rev-srv: ns.ripe.net + rev-srv: ns.eu.net + notify: ops@ripe.net + changed: tony@ripe.net 940110 + source: RIPE + + person: Daniel Karrenberg + address: RIPE Network Coordination Centre (NCC) + address: Kruislaan 409 + address: NL-1098 SJ Amsterdam + address: Netherlands + phone: +31 20 592 5065 + fax-no: +31 20 592 5090 + e-mail: dfk@ripe.net + nic-hdl: DK58 + changed: ripe-dbm@ripe.net 920826 + source: RIPE + + person: Marten Terpstra + address: RIPE Network Coordination Centre (NCC) + address: PRIDE Project + address: Kruislaan 409 + address: NL-1098 SJ Amsterdam + address: Netherlands + phone: +31 20 592 5064 + fax-no: +31 20 592 5090 + e-mail: Marten.Terpstra@ripe.net + nic-hdl: MT2 + notify: marten@ripe.net + changed: marten@ripe.net 931230 + source: RIPE + + + + Objects are stored and retrieved in this tag/value format. The RIPE + NCC does not provide differently formatted reports because any + desired format can easily be produced from this generic one. + + + + + + +Bates, et al. [Page 13] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Routing Registry Objects + + The main objects comprising the routing registry are "aut-num" and + "route", describing an autonomous system and a route respectively. It + should be noted that routes not described in the routing registry + should never be routed in the Internet itself. + + The autonomous system (aut-num) object provides contact information + for the AS and describes the routing policy of that AS. The routing + policy is described by enumerating all neighboring ASes with which + routing information is exchanged. For each neighbor the routing + policy is described in terms of exactly what is being sent + (announced) and allowed in (accepted). It is important to note that + this is exactly the part of the global policy over which an AS has + direct control. Thus each aut-num object describes what can indeed be + implemented and enforced locally by the AS concerned. Combined + together all the aut-num objects provide the global routing graph and + permit to deduce the exact routing policy between any two ASes. + + While the aut-num objects describe how routing information is + propagated, the route object describes a single route injected into + the external routing mesh. The route object references the AS + injecting (originating) the route and thereby indirectly provides + contact information for the originating AS. This reference also + provides the primary way of grouping routes into larger collections. + This is necessary because describing routing policy on the level of + single routes would be awkward to impractical given the number of + routes in the Internet which is about 20,000 at the time of this + writing. Thus routing policy is most often defined for groups of + routes by originating AS. This method of grouping is well supported + by current exterior routing protocols. The route object also + references community objects described below to provide another + method of grouping routes. Modification of aut-num object itself and + the referencing by route objects is strictly protected to provide + network operators control over the routing policy description and the + routes originated by their ASes. + + Sometimes even keeping track of groups of routes at the AS level is + cumbersome. Consider the case of policies described at the transit + provider level which apply transitively to all customers of the + transit provider. Therefore another level of grouping is provided by + the as-macro object which provides groups of ASes which can be + referenced in routing policies just like single ASes. Membership of + as-macro groups is also strictly controlled. + + Sometimes there is a need to group routes on different criteria than + ASes for purposes like statistics or local access policies. This is + provided by the community object. A community object is much like an + + + +Bates, et al. [Page 14] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + AS but without a routing policy. It just describes a group of + routes. This is not supported at all by exterior routing protocols + and depending on aggregation of routes may not be generally usable to + define routing policies. It is suitable for local policies and non- + routing related purposes. + + These routing related objects will be described in detail in the + sections below. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 15] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +5. The Route Object + + As stated in the previous chapter routing and address space + allocation information are now clearly separated. This is performed + with the introduction of the route object. The route object will + contain all the information regarding a routing announcement. + + All routing related attributes are removed from the inetnum object. + Some old attributes are obsoleted: connect, routpr-l, bdryg-l, nsf- + in, nsf-out, gateway). The currently useful routing attributes are + moved to the route object: aut-sys becomes origin, ias-int will be + encoded as part of the inet-rtr [15] object and comm-list simply + moves. See [6] for detail of the "inetnum" object definition. + + + The information in the old inetnum object + + inetnum: 192.87.45.0 + netname: RIPE-NCC + descr: RIPE Network Coordination Centre + descr: Amsterdam, Netherlands + country: NL + admin-c: Daniel Karrenberg + tech-c: Marten Terpstra + connect: RIPE NSF WCW + aut-sys: AS3333 + comm-list: SURFNET + ias-int: 192.87.45.80 AS1104 + ias-int: 192.87.45.6 AS2122 + ias-int: 192.87.45.254 AS2600 + rev-srv: ns.ripe.net + rev-srv: ns.eu.net + notify: ops@ripe.net + changed: tony@ripe.net 940110 + source: RIPE + + + will be distributed over two objects: + + + + + + + + + + + + + +Bates, et al. [Page 16] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + inetnum: 192.87.45.0 + netname: RIPE-NCC + descr: RIPE Network Coordination Centre + descr: Amsterdam, Netherlands + country: NL + admin-c: Daniel Karrenberg + tech-c: Marten Terpstra + rev-srv: ns.ripe.net + rev-srv: ns.eu.net + notify: ops@ripe.net + changed: tony@ripe.net 940110 + source: RIPE + + route: 192.87.45.0/24 + descr: RIPE Network Coordination Centre + origin: AS3333 + comm-list: SURFNET + changed: dfk@ripe.net 940427 + source: RIPE + + + + The route object is used to represent a single route originated into + the Internet routing mesh. The actual syntax is given in Appendix D. + However, there are several important aspects of the attributes worthy + of note. + + + The value of the route attribute will be a classless address. It + represents the exact route being injected into the routing mesh. The + representation of classless addresses is described in [10]. + + + The value of the origin attribute will be an AS reference of the form + AS1234 referring to an aut-num object. It represents the AS + injecting this route into the routing mesh. The "aut-num" object + (see below) thus referenced provides all the contact information for + this route. + + + Special cases: There can only be a single originating AS in each + route object. However in todays Internet sometimes a route is + injected by more than one AS. This situation is potentially dangerous + as it can create conflicting routing policies for that route and + requires coordination between the originating ASes. In the routing + registry this is represented by multiple route objects. + + + + +Bates, et al. [Page 17] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + This is a departure from the one route (net), one AS principle of the + ripe-81 routing registry. The consequences for the different tools + based in the routing registry will need to be evaluated and possibly + additional consistency checking of the database is needed. + + + The examples below will illustrate the usage of the route object + further. Suppose three chunks of address space of 2 different + enterprises represented by the following inetnum objects: + + + Examples + + + inetnum: 193.0.1.0 + netname: ENT-1 + descr: Enterprise 1 + ... + + inetnum: 193.0.8.0 + netname: ENT-2 + descr: Enterprise 2 + ... + + inetnum: 193.0.9.0 + netname: ENT-2-SPEC + descr: Enterprise 2 + ... + + + Supposing that the Enterprises have their own AS numbers straight + application of routing without aggregation would yield: + + + route: 193.0.1.0/24 + descr: Enterprise 1 + origin: AS1 + ... + + route: 193.0.8.0/24 + descr: Enterprise 2 + origin: AS2 + ... + + route: 193.0.9.0/24 + descr: Enterprise 2 + origin: AS2 + ... + + + +Bates, et al. [Page 18] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + NB: This representation can be achieved by straight translation from + the ripe-81 representation. See Appendix G for more details. + + + Homogeneous Aggregation + + The two chunks of address space of Enterprise 2 can be represented by + one aggregate route turning two route objects into one and + potentially saving routing table space for one route. + + + route: 193.0.8.0/23 + descr: Enterprise 2 + origin: AS2 + ... + + + Note that AS2 can also decide to originate all routes mentioned so + far, two 24-bit prefixes and one 23-bit prefix. This case would be + represented by storing all three route objects in the database. In + this particular example the additional routes will not add any + functionality however and only increase the amount of routes + announced unnecessarily. + + + Heterogeneous Aggregation + + Consider the following case however: + + + route: 193.0.8.0/24 + descr: Enterprise 2 + origin: AS2 + ... + + route: 193.0.9.0/24 + descr: Enterprise 2 / Special + origin: AS2 + comm-list: SPECIAL + ... + + + Now the prefix 193.0.9.0/24 belongs to community SPECIAL (this + community may well not be relevant to routing) and the other prefix + originated by AS2 does not. If AS2 aggregates these prefixes into the + 193.0.8.0/23 prefix, routing policies based on the community value + SPECIAL cannot be implemented in general, because there is no way to + distinguish between the special and the not-so-special parts of AS2. + + + +Bates, et al. [Page 19] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + If another AS has the policy to accept only routes to members of + community SPECIAL it cannot implement it, because accepting the route + to 193.0.8.0/23 would also route to 193.0.8.0/24 and not accepting + this route would lose connectivity to the special part 193.0.9.0/24. + We call aggregate routes consisting of components belonging to + different communities or even different ASes "heterogeneous + aggregates". + + The major problem introduced with heterogeneous aggregates is that + once the homogeneous more specific routes are withdrawn one cannot + tell if a more specific part of the heterogeneous route has a + different policy. However, it can be counter argued that knowing this + policy is of little use since a routing policy based on the less + specific heterogeneous aggregate only cannot be implemented. In fact, + this displays a facet of CIDR itself in that one may actually trade + off implementing slight policy variations over announcing a larger + (albeit heterogeneous in terms of policy) aggregate to save routing + table space. + + However, it is still useful to be able to document these variations + in policy especially when this homogeneous more specific route is + just being withdrawn. For this one can use the "withdrawn" attribute. + The withdrawn attribute can serve to both indicate that a less + specific aggregate is in fact heterogeneous and also allow the + general documenting of route withdrawal. + + So there has to be a way for AS2 to document this even if it does not + originate the route to 193.0.9.0/24 any more. This can be done with + the "withdrawn" attribute of the route object. The aggregate route + to 193.0.8.0/23 is now be registered as: + + + route: 193.0.8.0/23 + descr: Enterprise 2 + origin: AS2 + ... + + + With the two homogeneous routes marked as withdrawn from the Internet + routing mesh but still preserving their original routing information. + + + + + + + + + + + +Bates, et al. [Page 20] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + route: 193.0.8.0/24 + descr: Enterprise 2 + origin: AS2 + withdrawn: 940701 + ... + + route: 193.0.9.0/24 + descr: Enterprise 2 / Special + origin: AS2 + comm-list: SPECIAL + withdrawn: 940701 + ... + + + It should be noted that the date value used in the withdrawn + attribute can only be in the past. + + + Proxy Aggregation + + The next step of aggregation are aggregates consisting of more than + one AS. This generally means one AS is aggregating on behalf of + another. It is called proxy aggregation. Proxy aggregation should be + done with great care and always be coordinated with other providers + announcing the same route. + + Consider the following: + + + route: 193.0.0.0/20 + descr: All routes known by AS1 in a single package + origin: AS1 + ... + + + + route: 193.0.1.0/24 + descr: Foo + origin: AS1 + withdrawn: 940310 + ... + + + + + + + + + +Bates, et al. [Page 21] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + route: 193.0.8.0/24 + descr: Bar + origin: AS2 + withdrawn: 940310 + ... + + + + route: 193.0.9.0/24 + descr: Bar-2 + origin: AS2 + withdrawn: 940310 + comm-list: SPECIAL + ... + + + + + + If AS1 announced no other routes to a single homed neighboring AS, + that neighbor can in general either take that route or leave it but + not differentiate between AS1 and AS2. + + Note: If the neighbor was previously configured to accept routes + originating in AS2 but not in AS1 they lose connectivity to AS2 as + well. This means that proxy aggregation has to be done carefully and + in a well coordinated fashion. The information in the withdrawn route + object can help to achieve that. + + + Aggregates with Holes + + If we assume that the world of our example still consists of only + three chunks of address space the aggregate above contains what are + called holes, parts of an aggregate that are not reachable via the + originator of the route. From the routing information itself one + cannot tell whether these are holes and what part of the route falls + inside one. The only way to tell is to send a packet there and see + whether it gets to the destination, or an ICMP message is received + back, or there is silence. On the other hand announcing aggregates + with holes is quite legitimate. Consider a 16-bit aggregate with + only one 24-bit prefix unreachable. The savings in routing table + size by far outweigh the hole problem. + + For operational reasons however it is very useful to register these + holes in the routing registry. Consider the case where a remote + network operator experiences connectivity problems to addresses + + + +Bates, et al. [Page 22] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + inside an aggregate route. If the packets are getting to the AS + announcing the aggregate and there are no more specific routes, the + normal cause of action is to get in touch with the originating AS of + the aggregate route and ask them to fix the problem. If the address + falls into a hole this is futile. Therefore problem diagnosis can be + sped up and unnecessary calls prevented by registering the holes in + the routing registry. We do this by using the "hole" attribute. In + our example the representation would be: + + + route: 193.0.0.0/20 + descr: All routes known by AS1 + origin: AS1 + hole: 193.0.0.0/24 + hole: 193.0.2.0/23 + hole: 193.0.4.0/22 + hole: 193.0.10.0/23 + hole: 193.0.12.0/22 + ... + + + Note: there would also be two routes with the withdrawn attribute as + displayed above (i.e. 193.0.8.0/24 and 193.0.9.0/24). It is not + mandatory to document all holes. It is recommended all holes routed + by another service provider are documented. + + Multiple Proxy Aggregation + + Finally suppose that AS2 decides to announce the same aggregate, as + in the previous example, they would add the following route object to + the registry: + + + route: 193.0.0.0/20 + descr: All routes known by AS2 + origin: AS2 + hole: 193.0.0.0/24 + hole: 193.0.2.0/23 + hole: 193.0.4.0/22 + hole: 193.0.10.0/23 + hole: 193.0.12.0/22 + ... + + + Both AS1 and AS2 will be notified that there already is a route to + the same prefix in the registry. + + + + + +Bates, et al. [Page 23] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + This multiple proxy aggregation is very dangerous to do if the sub- + aggregates of the route are not the same. It is still dangerous when + the sub-aggregates are consistent but connectivity to the sub- + aggregates varies widely between the originators. + + + + Route object update procedures + + Adding a route object will have to be authorised by the maintainer of + the originating AS. The actual implementation of this is outside the + scope of this document. This guarantees that an AS guardian has full + control over the registration of the routes it announces [11]. + + + What is an Inter-AS network ? + + An inter-AS network (Inter-AS IP networks are those networks are + currently called FIXes, IXFs, DMZs, NAPs, GIX and many other + acronyms) exists for the purpose of passing traffic and routing + information between different autonomous systems. The most simple + example of an inter-AS network is a point-to-point link, connecting + exactly two ASes. Each end of such a link is connected to an + interface of router belonging to each of the autonomous systems. + More complex examples are broadcast type networks with multiple + interfaces connecting multiple ASes with the possibility of more than + one connection per AS. Consider the following example of three + routers 1, 2 and 3 with interfaces a through f connected by two + inter-AS networks X and Y: + + + X Y + a1b --- c2d --- e3f + + + + Suppose that network X is registered in the routing registry as part + of AS1 and net Y as part of AS3. If traffic passes from left to right + prtraceroute will report the following sequence of interfaces and + ASes: + + a in AS1 + c in AS1 + e in AS3 + + + The traceroute algorithm enumerates only the receiving interfaces on + the way to the destination. In the example this leads to the passage + + + +Bates, et al. [Page 24] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + of AS2 going unnoticed. This is confusing to the user and will also + generate exceptions when the path found is checked against the + routing registry. + + + For operational monitoring tools such as prtraceroute it is necessary + to know which interface on an inter-AS network belongs to which AS. + If AS information is not known about interfaces on an inter-AS + network, tools like prtraceroute cannot determine correctly which + ASes are being traversed. + + + All interfaces on inter-AS networks will are described in a separate + object know as the `inet-rtr' object [15]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 25] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +6. The Autonomous System Object + + + Autonomous Systems + + An Autonomous System (AS) is a group of IP networks operated by one + or more network operators which has a single and clearly defined + external routing policy. + + An AS has a unique number associated with it which is used both in + exchange of exterior routing information and as an identifier of the + AS itself. Exterior routing protocols such as BGP and EGP are used + to exchange routing information between ASes. + + In routing terms an AS will normally use one or more interior gateway + protocols (IGPs) in conjunction with some sort of common agreed + metrics when exchanging network information within its own AS. + + The term AS is often confused or even misused as a convenient way of + grouping together a set of networks which belong under the same + administrative umbrella even if within that group of networks there + are various different routing policies. We provide the "community" + concept for such use. ASes can strictly have only one single + external routing policy. + + The creation of an AS should be done in a conscious and well + coordinated manner to avoid creating ASes for the sake of it, perhaps + resulting in the worst case scenario of one AS per routing + announcement. It should be noted that there is a limited number of + AS numbers available. Also creating an AS may well increase the + number of AS paths modern EGPs will have to keep track of. This + aggravates what is known as "the routing table growth problem". This + may mean that by applying the general rules for the creation and + allocation of an AS below, some re-engineering may well be needed. + However, this may be the only way to actually implement the desired + routing policy anyway. The creation and allocation of an AS should + be done with the following recommendations in mind: + + + + Creation of an AS is only required when exchanging routing + information with other ASes. Some router implementations make + use of an AS number as a form of tagging to identify the routing + process. However, it should be noted that this tag does not + need to be unique unless routing information is indeed exchanged + with other ASes. + + + + + + +Bates, et al. [Page 26] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + For a simple case of customer networks connected to a single + service provider, the IP network should normally be a member of + the service providers AS. In terms of routing policy the IP + network has exactly the same policy as the service provider and + there is no need to make any distinction in routing information. + This idea may at first seem slightly alien to some, but it + highlights the clear distinction in the use of the AS number as + a representation of routing policy as opposed to some form of + administrative use. + + + + If a network operator connects to more than one AS with + different routing policies then they need to create their own + AS. In the case of multi-homed customer networks connected to + two service providers there are at least two different routing + policies to a given customer network. At this point the + customer networks will be part of a single AS and this AS would + be distinct from either of the service providers ASes. This + allows the customer the ability of having a different + representation of policy and preference to the different service + providers. This is the ONLY case where a network operator + should create its own AS number. + + + + As a general rule one should always try to populate the AS with + as many routes as possible, providing all routes conform to the + same routing policy. + + + Each AS is represented in the RIPE database by both an aut-num object + and the route objects representing the routes originated by the AS. + The aut-num object stores descriptive, administrative and contact + information about the AS as well as the routing policies of the AS in + relation to all neighboring ASes. + + The origin attributes of the route objects define the set of routes + originated by the AS. Each route object can have exactly one origin + attribute. Route objects can only be created and updated by the + maintainer of the AS and not by those immediately responsible for the + particular routes referenced therein. This ensures that operators, + especially service providers, remain in control of AS routing + announcements. + + + The AS object itself is used to represent a description of + administrative details and the routing policies of the AS itself. The + AS object definition is depicted as follows. + + + + +Bates, et al. [Page 27] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + Example: + + aut-num: AS1104 + descr: NIKHEF-H Autonomous system + as-in: from AS1213 100 accept AS1213 + as-in: from AS1913 100 accept AS1913 + as-in: from AS1755 150 accept ANY + as-out: to AS1213 announce ANY + as-out: to AS1913 announce ANY + as-out: to AS1755 announce AS1104 AS1913 AS1213 + tech-c: Rob Blokzijl + admin-c: Eric Wassenaar + guardian: as-guardian@nikhef.nl + changed: ripe-dbm@ripe.net 920910 + source: RIPE + + + + See Appendix A for a complete syntax definition of the "aut-num" + object. + + + It should be noted that this representation provides two things: + + + a set of routes. + + + a description of administrative details and routing policies. + + The set of routes can be used to generate network list based + configuration information as well as configuration information for + exterior routing protocols knowing about ASes. This means an AS can + be defined and is useful even if it does not use routing protocols + which know about the AS concept. + + + + + + + + + + + + + + + + + +Bates, et al. [Page 28] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Description of routing policies between ASs with multiple connections + - "interas-in/interas-out" + + The following section is only relevant for ASes which use different + policies on multiple links to the same neighboring AS. Readers not + doing this may want to skip this section. + + Description of multiple connections between ASs defines how two ASs + have chosen to set different policies for the use of each or some of + the connections between the ASs. This description is necessary only + if the ASs are connected in more than one way and the routing policy + and differs at these two connections. + + + + Example: + + + LINK1 + 193.0.1.1 +----------+ 193.0.1.2 + | | + AS1------AS2== ==AS3-----AS4 + | | + 193.0.1.5 +----------+ 193.0.1.6 + LINK2 + + + + Note: LINK here denotes the peer connection points between + ASs. It is not necessarily just a serial link. It could + be ethernet or any other type of connection as well. It + can also be a peer session where the address is the same at + one end and different at the other end. + + + It may be that AS2 wants to use LINK2 only for traffic towards AS4. + LINK1 is used for traffic to AS3 and as backup to AS4, should LINK2 + fail. To implement this policy, one would use the attribute + "interas-in" and "interas-out." This attribute permits ASs to + describe their local decisions based on its preference such as + multi-exit-discriminators (MEDs) as used in some inter-domain routing + protocols (BGP4, IDRP) and to communicate those routing decisions. + This information would be useful in resolving problems when some + traffic paths changed from traversing AS3's gateway in Timbuktu + rather than the gateway in Mogadishu. The exact syntax is given in + Appendix A. However, if we follow this example through in terms of + AS2 we would represent this policy as follows: + + + + +Bates, et al. [Page 29] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + Example: + + aut-num: AS2 + as-in: from AS3 10 accept AS3 AS4 + as-out: to AS3 announce AS1 AS2 + interas-in:from AS3 193.0.1.1/32 193.0.1.2/32 (pref=5) accept AS3 + interas-in:from AS3 193.0.1.1/32 193.0.1.2/32 (pref=9) accept AS4 + interas-in:from AS3 193.0.1.5/32 193.0.1.6/32 (pref=7) accept AS4 + ... + + + + Here we see additional policy information between two ASs in terms of + the IP addresses of the connection. The parentheses and keyword are + syntactic placeholders to add the readability of the attributes. If + pref=MED is specified the preference indicated by the remote AS via + the multi-exit- discriminator metric such as BGP is used. Of course + this type on inter-AS policy should always be bilaterally agreed upon + to avoid asymmetry and in practice there may need to be + corresponding interas-out attributes in the policy representation of + AS3. + + + The interas-out attribute is similar to interas-in as as-out is to + as-in. The one major difference being that interas-out allows you to + associate an outgoing metric with each route. It is important to note + that this metric is just passed to the peer AS and it is at the peer + AS's discretion to use or ignore it. A special value of IGP + specifies that the metric passed to the receiving AS will be derived + from the IGP of the sending AS. In this way the peer AS can choose + the optimal link for its traffic as determined by the sending AS. + + If we look at the corresponding interas-out for AS3 we would see the + following: + + Example: + +aut-num: AS3 +as-in: from AS2 10 accept AS1 A2 +as-out: to AS2 announce AS3 AS4 +interas-out:to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=5) announce AS3 +interas-out:to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=9) announce AS4 +interas-out:to AS2 193.0.1.6/32 193.0.1.5/32 (metric-out=7) announce AS4 + ... + + + + + + +Bates, et al. [Page 30] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Descriptions of interas policies do not replace the global + policy described in as-in, as-out and other policy attributes which + should be specified too. If the global policy mentions more routes + than the combined local policies then local preferences for these + routes are assumed to be equal for all links. + + Any route specified in interas-in/out and not specified in as-in/out + is assumed not accepted/announced between the ASes concerned. + Diagnostic tools should flag this inconsistency as an error. It + should be noted that if an interas-in or interas-out policy is + specified then it is mandatory to specify the corresponding global + policy in the as-in or as-out line. Please note there is no relevance + in the cost associated with as-in and the preferences used in + interas-in. + + The interaction of interas-in/interas-out with as-in/as-out + + Although formally defined above, the rules associated with policy + described in terms of interas-in and interas-out with respect to as- + in and as-out are worthy of clarification for implementation. + + When using interas-in or interas-out policy descriptions, one must + always make sure the set of policies described between two ASes is + always equal to or a sub-set of the policy described in the global + as-in or as-out policy. When a sub-set is described remember the + remaining routes are implicitly shared across all connections. It is + an error for the interas policies to describe a superset of the + global policies, i.e. to announce or accept more routes than the + global policies. + + When defining complex interas based policies it is advisable to + ensure that any possible ambiguities are not present by explicitly + defining your policy with respect to the global as-in and as-out + policy. + + If we look at a simple example, taking just in-bound announcements to + simplify things. If we have the following global policy: + + + aut-num: AS1 + as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} + + Suppose there are three peerings between AS1 and AS2, known as L1-R1, + L2-R2 and L3-R3 respectively. The actual policy of these connections + is to accept AS100 equally on these three links and just route + 10.0.0.0/8 on L3-R3. The simple way to mention this exception is to + just specify an interas policy for L3-R3: + + + + +Bates, et al. [Page 31] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} + + + The implicit rule that all routes not mentioned in interas policies + are accepted on all links with equal preference ensures the desired + result. + + The same policy can be written explicitly as: + + interas-in: from AS2 L1 R1 (pref=100) accept AS100 + interas-in: from AS2 L2 R2 (pref=100) accept AS100 + interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} + + + Whilst this may at first sight seem obvious, the problem arises when + not all connections are mentioned. For example, if we specified only + an interas-in line for L3-R3 as below: + + aut-num: AS1 + as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} + interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} + + + then the policy for the other links according to the rules above + would mean they were equal to the global policy minus the sum of the + local policies (i.e. ((AS100 OR {10.0.0.0/0}) / (AS100 OR + {10.0.0.0/0})) = empty) which in this case would mean nothing is + accepted on connections L1-R1 and L2-R2 which is incorrect. + + Another example: If we only registered the policy for link L2- + R2: + + interas-in: from AS2 L2 R2 (pref=100) accept AS100 + + The implicit policy for both L1-R1 and L3-R3 would be as follows: + + interas-in: from AS2 L1 R1 (pref=100) accept {10.0.0.0/8} + interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} + + + This is derived as the set of global policies minus the set of + interas-in policies (in this case just accept AS100 as it was the + L2-R2 interas-in policy we registered) with equal cost for the + remaining connection. This again is clearly not what was intended. + + + + + + +Bates, et al. [Page 32] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + We strongly recommend that you always mention all policies for all + interas connections explicitly, to avoid these possible errors. One + should always ensure the set of the interas policies is equal to the + global policy. Clearly if interas policies differ in complex ways it + is worth considering splitting the AS in question into separate ASes. + However, this is beyond the direct scope of this document. + + It should also be noted there is no direct relationship between the + cost used in as-in and the preference used in interas-in. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 33] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + How to describe the exclusion policy of a certain AS - "as-exclude" + + Some ASes have a routing policy based on the exclusion of certain + routes if for whatever reason a certain AS is used as transit. + Whilst, this is in general not good practice as it makes implicit + assumptions on topology with asymmetry a possible outcome if not + coordinated, this case needs to be accommodated within the routing + policy representation. + + The way this is achieved is by making use of the "as-exclude" + attribute. The precise syntax of this attribute can be found in + Appendix A along with the rest of the defined syntax for the "aut- + num" object. However, some explanation of the use of this attribute + is useful. If we have the following example topology. + + Example: + + + AS4--------AS3 + | | | + | | | + AS1--------AS2--------AS5 + + + With a simple corresponding policy like so: + + + Example: + + aut-num: AS1 + as-in: from AS2 100 accept ANY + as-out: to AS2 announce AS1 + as-exclude: exclude AS4 to ANY + .... + + + We see an interesting policy. What this says in simple terms is AS1 + doesn't want to reach anything if it transits AS4. This can be a + perfectly valid policy. However, it should be realized that if for + whatever reason AS2 decides to route to AS3 via AS4 then immediately + AS1 has no connectivity to AS3 or if AS1 is running default to AS2 + packets from AS1 will still flow via AS4. The important point about + this is that whilst AS1 can advise its neighbors of its policy it has + no direct control on how it can enforce this policy to neighbors + upstream. + + + + + + +Bates, et al. [Page 34] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Another interesting scenario to highlight the unexpected result of + using such an "as-exclude" policy. If we assume in the above example + AS2 preferred AS4 to reach AS3 and AS1 did not use default routing + then as stated AS1 would have no connectivity to AS3. Now lets + suppose that for example the link between AS2 and AS4 went down for + some reason. Like so: + + Example: + + + + AS4--------AS3 + | + | + AS1--------AS2--------AS5 + + + Suddenly AS1 now has connectivity to AS3. This unexpected behavior + should be considered when created policies based on the "as-exclude" + attribute. + + The second problem with this type of policy is the potential of + asymmetry. In the original example we saw the correct policy from + AS1's point of view but if ASes with connectivity through AS4 do not + use a similar policy you have asymmetric traffic and policy. If an + AS uses such a policy they must be aware of the consequences of its + use. Namely that the specified routes which transit the AS (i.e. + routing announcements with this AS in the AS path information) in + question will be excluded. If not coordinated this can easily cause + asymmetry or even worse loss of connectivity to unknown ASes behind + (or in front for that matter) the transit AS in question. With this + in mind this attribute can only be viewed as a form of advisory to + other service providers. However, this does not preclude its use with + policy based tools if the attribute exists. + + By having the ability to specify a route keyword based on any of the + four notations given in the syntax it allows the receiving AS to + specify what routes it wishes to exclude through a given transit AS + to a network granularity. + + + + + + + + + + + + +Bates, et al. [Page 35] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +7. AS Macros + + It may be difficult to keep track of each and every new AS that is + represented in the routing registry. A convenient way around this is + to define an `AS Macro' which essentially is a convenient way to + group ASes. This is done so that each and every AS guardian does not + have to add a new AS to it's routing policy as described by the as-in + and as-out attributes of it's AS object. + + However, it should be noted that this creates an implicit trust on + the guardian of the AS-Macro. + + An AS-Macro can be used in for the "as- + in" and "as-out" attributes in the aut-num object. The AS-Macro + object is then used to derive the list or group of ASes. + + A simple example would be something like: + + + Example: + + aut-num: AS786 + as-in: from AS1755 100 accept AS-EBONE AND NOT AS1104 + as-out to AS1755 announce AS786 + ..... + + + Where the as-macro object for AS-EBONE is as follows: + + + as-macro: AS-EBONE + descr: ASes routed by EBONE + as-list: AS2121 AS1104 AS2600 AS2122 + as-list: AS1103 AS1755 AS2043 + guardian: guardian@ebone.net + ...... + + + So the policy would be evaluated to: + + + aut-num: AS786 + as-in: from AS1755 100 accept (AS2121 OR AS1104 OR AS2600 OR AS2122 + as-in: from AS1755 100 accept AS1103 OR AS1755 OR + as-in: from AS1755 100 accept AS2043) AND NOT AS1104 + ...... + + + + + +Bates, et al. [Page 36] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + It should be noted that the above examples incorporates the rule for + line wrapping as defined in Appendix A for policy lines. See + Appendix C for a definition on the AS-Macro syntax. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 37] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +8. The Community Object + + A community is a group of routes that cannot be represented by an AS + or a group of ASes. It is in some circumstances useful to define a + group of routes that have something in common. This could be a + special access policy to a supercomputer centre, a group of routes + used for a specific mission, or a disciplinary group that is + scattered among several autonomous systems. Also these communities + could be useful to group routes for the purpose of network + statistics. + + Communities do not exchange routing information, since they do not + represent an autonomous system. More specifically, communities do + not define routing policies, but access or usage policies. However, + they can be used as in conjunction with an ASes routing policy to + define a set of routes the AS sets routing policy for. + + Communities should be defined in a strict manner, to avoid creating + as many communities as there are routes, or even worse. Communities + should be defined following the two rules below; + + + + Communities must have a global meaning. Communities that have + no global meaning, are used only in a local environment and + should be avoided. + + + + Communities must not be defined to express non-local policies. + It should be avoided that a community is created because some + other organization forces a policy upon your organization. + Communities must only be defined to express a policy defined by + your organization. + + + + Community examples + + There are some clear examples of communities: + + + BACKBONE - + all customers of a given backbone service provider even though + they can have various different routing policies and hence + belong to different ASes. This would be extremely useful for + statistics collection. + + + + + + +Bates, et al. [Page 38] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + HEPNET - + the High Energy Physics community partly shares infrastructure + with other organizations, and the institutes it consists of are + scattered all over Europe, often being part of a non HEPNET + autonomous system. To allow statistics, access or part of a + routing policy , a community HEPNET, consisting of all routes + that are part of HEPNET, conveniently groups all these routes. + + + NSFNET - + the National Science Foundation Network imposes an acceptable + use policy on routes that wish to make use of it. A community + NSFNET could imply the set of routes that comply with this + policy. + + + MULTI - + a large multinational corporation that does not have its own + internal infrastructure, but connects to the various parts of + its organizations by using local service providers that connect + them all together, may decide to define a community to restrict + access to their networks, only by networks that are part of this + community. This way a corporate network could be defined on + shared infrastructure. Also, this community could be used by any + of the service providers to do statistics for the whole of the + corporation, for instance to do topology or bandwidth planning. + + + Similar to Autonomous systems, each community is represented in the + RIPE database by both a community object and community tags on the + route objects representing the routes belonging to the community. + The community object stores descriptive, administrative and contact + information about the community. + + The community tags on the route objects define the set of routes + belonging to a community. A route can have multiple community tags. + The community tags can only be created and updated by the "guardian" + of the community and not by those directly responsible for the + particular network. This ensures that community guardians remain in + control of community membership. + + Here's an example of how this might be represented in terms of the + community tags within the network object. We have an example where + the route 192.16.199.0/24 has a single routing policy (i.e. that of + AS 1104), but is part of several different communities of interest. + We use the tag "comm-list" to represent the list of communities + associated with this route. NIKHEF-H uses the service provider + SURFNET (a service provider with customers with more than one routing + + + +Bates, et al. [Page 39] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + policy), is also part of the High Energy Physics community as well as + having the ability to access the Supercomputer at CERN (the community + `CERN-SUPER', is somewhat national, but is intended as an example of + a possible use of an access policy constraint). + + + Example: + + route: 192.16.199.0/24 + descr: Local Ethernet + descr: NIKHEF section H + origin: AS1104 + comm-list: HEPNET CERN-SUPER SURFNET + changed: ripe-dbm@ripe.net 920604 + source: RIPE + + + + In the above examples some communities have been defined. The + community object itself will take the following format: + + + Example: + + community: SURFNET + descr: Dutch academic research network + authority: SURFnet B.V. + guardian: comm-guardian@surfnet.nl + admin-c: Erik-Jan Bos + tech-c: Erik-Jan Bos + changed: ripe-dbm@ripe.net 920604 + source: RIPE + + For a complete explanation of the syntax please refer to Appendix B. + + + + + + + + + + + + + + + + + +Bates, et al. [Page 40] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +9. Representation of Routing Policies + + Routing policies of an AS are represented in the autonomous system + object. Initially we show some examples, so the reader is familiar + with the concept of how routing information is represented, used and + derived. Refer to Appendix A, for the full syntax of the "aut-num" + object. + + The topology of routing exchanges is represented by listing how + routing information is exchanged with each neighboring AS. This is + done separately for both incoming and outgoing routing information. + In order to provide backup and back door paths a relative cost is + associated with incoming routing information. + + + Example 1: + + + AS1------AS2 + + + This specifies a simple routing exchange of two presumably isolated + ASes. Even if either of them has routing information about routes in + ASes other than AS1 and AS2, none of that will be announced to the + other. + + aut-num: AS1 + as-out: to AS2 announce AS1 + as-in: from AS2 100 accept AS2 + + aut-num: AS2 + as-out: to AS1 announce AS2 + as-in: from AS1 100 accept AS1 + + + The number 100 in the in-bound specifications is a relative cost, + which is used for backup and back door routes. The absolute value is + of no significance. The relation between different values within the + same AS object is. A lower value means a lower cost. This is + consciously similar to the cost based preference scheme used with DNS + MX RRs. + + + Example 2: + + Now suppose that AS2 is connected to one more AS, besides AS1, and + let's call that AS3: + + + + +Bates, et al. [Page 41] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + + AS1------AS2------AS3 + + + + In this case there are two reasonable routing policies: + + a) AS2 just wants to exchange traffic with both AS1 and AS3 itself + without passing traffic between AS1 and AS3. + + b) AS2 is willing to pass traffic between AS3 and AS1, thus acting + as a transit AS + + + Example 2a: + + In the first case AS1's representation in the routing registry will + remain unchanged as will be the part of AS2's representation + describing the routing exchange with AS1. A description of the + additional routing exchange with AS3 will be added to AS2's + representation: + + + aut-num: AS1 + as-out: to AS2 announce AS1 + as-in: from AS2 100 accept AS2 + + aut-num: AS2 + as-out: to AS1 announce AS2 + as-in: from AS1 100 accept AS1 + as-out: to AS3 announce AS2 + as-in: from AS3 100 accept AS3 + + aut-num: AS3 + as-out: to AS2 announce AS3 + as-in: from AS2 100 accept AS2 + + + Note that in this example, AS2 keeps full control over its resources. + Even if AS3 and AS1 were to allow each others routes in from AS2, the + routing information would not flow because AS2 is not announcing it. + Of course AS1 and AS3 could just send traffic to each other to AS2 + even without AS2 announcing the routes, hoping that AS2 will forward + it correctly. Such questionable practices however are beyond the + scope of this document. + + + + + +Bates, et al. [Page 42] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Example 2b: + + If contrary to the previous case, AS1 and AS3 are supposed to have + connectivity to each other via AS2, all AS objects have to change: + + + aut-num: AS1 + as-out: to AS2 announce AS1 + as-in: from AS2 100 accept AS2 AS3 + + aut-num: AS2 + as-out: to AS1 announce AS2 AS3 + as-in: from AS1 100 accept AS1 + as-out: to AS3 announce AS2 AS1 + as-in: from AS3 100 accept AS3 + + aut-num: AS3 + as-out: to AS2 announce AS3 + as-in: from AS2 100 accept AS1 AS2 + + + + Note that the amount of routing information exchanged with a neighbor + AS is defined in terms of routes belonging to ASes. In BGP terms + this is the AS where the routing information originates and the + originating AS information carried in BGP could be used to implement + the desired policy. However, using BGP or the BGP AS-path + information is not required to implement the policies thus specified. + Configurations based on route lists can easily be generated from the + database. The AS path information, provided by BGP can then be used + as an additional checking tool as desired. + + The specification understands one special expression and this can be + expressed as a boolean expression: + + + ANY - means any routing information known. For output this means that + all routes an AS knows about are announced. For input it means + that anything is accepted from the neighbor AS. + + + + + + + + + + + + +Bates, et al. [Page 43] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Example 3: + + AS4 is a stub customer AS, which only talks to service provider + AS123. + + + | + | + -----AS123------AS4 + | + | + + + + aut-num: AS4 + as-out: to AS123 announce AS4 + as-in: from AS123 100 accept ANY + + aut-num: AS123 + as-in: from AS4 100 accept AS4 + as-out: to AS4 announce ANY + + + + + Since AS4 has no other way to reach the outside world than AS123 it + is not strictly necessary for AS123 to send routing information to + AS4. AS4 can simply send all traffic for which it has no explicit + routing information to AS123 by default. This strategy is called + default routing. It is expressed in the routing registry by adding + one or more default tags to the autonomous system which uses this + strategy. In the example above this would look like: + + + aut-num: AS4 + as-out: to AS123 announce AS4 + default: AS123 100 + + aut-num: AS123 + as-in: from AS4 100 accept AS4 + + + + + + + + + + + +Bates, et al. [Page 44] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Example 4: + + AS4 now connects to a different operator, AS5. AS5 uses AS123 for + outside connectivity but has itself no direct connection to AS123. + AS5 traffic to and from AS123 thus has to pass AS4. AS4 agrees to + act as a transit AS for this traffic. + + + | + | + -----AS123------AS4-------AS5 + | + | + + + + aut-num: AS4 + as-out: to AS123 announce AS4 AS5 + as-in: from AS123 100 accept ANY + as-out: to AS5 announce ANY + as-in: from AS5 50 accept AS5 + + aut-num: AS5 + as-in: from AS4 100 accept ANY + as-out: to AS4 announce AS5 + + aut-num: AS123 + as-in: from AS4 100 accept AS4 AS5 + as-out: to AS4 announce ANY + + + + + Now AS4 has two sources of external routing information. AS5 which + provides only information about its own routes and AS123 which + provides information about the external world. Note that AS4 accepts + information about AS5 from both AS123 and AS5 although AS5 + information cannot come from AS123 since AS5 is connected only via + AS4 itself. The lower cost of 50 for the announcement from AS5 itself + compared to 100 from AS123 ensures that AS5 is still believed even in + case AS123 will unexpectedly announce AS5. + + In this example too, default routing can be used by AS5 much like in + the previous example. AS4 can also use default routing towards + AS123: + + + + + + +Bates, et al. [Page 45] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + aut-num: AS4 + as-out: to AS123 announce AS4 AS5 + default: AS123 11 + as-in: from AS5 50 accept AS5 + + Note no announcements to AS5, they default to us. + + aut-num: AS5 + as-out: to AS4 announce AS5 + default: AS4 100 + + aut-num: AS123 + as-in: from AS4 100 announce AS4 AS5 + + + + Note that the relative cost associated with default routing is + totally separate from the relative cost associated with in-bound + announcements. The default route will never be taken if an explicit + route is known to the destination. Thus an explicit route can never + have a higher cost than the default route. The relative cost + associated with the default route is only useful in those cases where + one wants to configure multiple default routes for redundancy. + + Note also that in this example the configuration using default routes + has a subtly different behavior than the one with explicit routes: In + case the AS4-AS5 link fails AS4 will send traffic to AS5 to AS123 + when using the default configuration. Normally this makes not much + difference as there will be no answer and thus little traffic. With + certain datagram applications which do not require acknowledgments + however, significant amounts of traffic may be uselessly directed at + AS123. Similarly default routing should not be used if there are + stringent security policies which prescribe any traffic intended for + AS5 to ever touch AS123. + + Once the situation gets more complex using default routes can lead to + unexpected results or even defeat the routing policies established + when links fail. As an example consider how Example 5a) below could + be implemented using default routing. Therefore, generally it can be + said that default routing should only be used in very simple + topologies. + + + + + + + + + +Bates, et al. [Page 46] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Example 5: + + In a different example AS4 has a private connection to AS6 which in + turn is connected to the service provider AS123: + + + | + | + -----AS123------AS4 + | | + | | + | | + AS6 ---------+ + + + There are a number of policies worth examining in this case: + + + a) AS4 and AS6 wish to exchange traffic between themselves + exclusively via the private link between themselves; such + traffic should never pass through the backbone (AS123). The + link should never be used for transit traffic, i.e. traffic not + both originating in and destined for AS4 and AS6. + + + b) AS4 and AS6 wish to exchange traffic between themselves via the + private link between themselves. Should the link fail, traffic + between AS4 and AS6 should be routed via AS123. The link should + never be used for transit traffic. + + + c) AS4 and AS6 wish to exchange traffic between themselves via the + private link between themselves. Should the link fail, traffic + between AS4 and AS6 should be routed via AS123. Should the + connection between AS4 and AS123 fail, traffic from AS4 to + destinations behind AS123 can pass through the private link and + AS6's connection to AS123. + + + d) AS4 and AS6 wish to exchange traffic between themselves via the + private link between themselves. Should the link fail, traffic + between AS4 and AS6 should be routed via AS123. Should the + backbone connection of either AS4 or AS6 fail, the traffic of + the disconnected AS should flow via the other AS's backbone + connection. + + + + + + +Bates, et al. [Page 47] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Example 5a: + + + + aut-num: AS4 + as-in: from AS123 100 accept NOT AS6 + as-out: to AS123 announce AS4 + as-in: from AS6 50 accept AS6 + as-out: to AS6 announce AS4 + + aut-num: AS123 + as-in: from AS4 100 accept AS4 + as-out: to AS4 announce ANY + as-in: from AS6 100 accept AS6 + as-out: to AS6 announce ANY + + + aut-num: AS6 + as-in: from AS123 100 accept NOT AS4 + as-out: to AS123 announce AS6 + as-in: from AS4 50 accept AS4 + as-out: to AS4 announce AS6 + + + + Note that here the configuration is slightly inconsistent. AS123 will + announce AS6 to AS4 and AS4 to AS6. These announcements will be + filtered out on the receiving end. This will implement the desired + policy. Consistency checking tools might flag these cases however. + + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 48] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Example 5b: + + + + aut-num: AS4 + as-in: from AS123 100 accept ANY + as-out: to AS123 announce AS4 + as-in: from AS6 50 accept AS6 + as-out: AS6 AS4 + + aut-num: AS123 + as-in: AS4 100 AS4 + as-out: AS4 ANY + as-in: AS6 100 AS6 + as-out: AS6 ANY + + + aut-num: AS6 + as-in: from AS123 100 accept ANY + as-out: to AS123 announce AS6 + as-in: from AS4 50 accept AS4 + as-out: to AS4 announce AS6 + + + + The thing to note here is that in the ideal operational case, `all + links working' AS4 will receive announcements for AS6 from both AS123 + and AS6 itself. In this case the announcement from AS6 will be + preferred because of its lower cost and thus the private link will be + used as desired. AS6 is configured as a mirror image. + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 49] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Example 5c: + + The new feature here is that should the connection between AS4 and + AS123 fail, traffic from AS4 to destinations behind AS123 can pass + through the private link and AS6's connection to AS123. + + + aut-num: AS4 + as-in: from AS123 100 accept ANY + as-out: to AS123 announce AS4 + as-in: from AS6 50 accept AS6 + as-in: from AS6 110 accept ANY + as-out: to AS6 AS4 + + aut-num: AS123 + as-in: from AS4 1 accept AS4 + as-out: to AS4 announce ANY + as-in: from AS6 1 accept AS6 + as-in: from AS6 2 accept AS4 + as-out: to AS6 announce ANY + + + aut-num: AS6 + as-in: from AS123 100 accept ANY + as-out: to AS123 AS6 announce AS4 + as-in: from AS4 50 accept AS4 + as-out: to AS4 announce ANY + + + + Note that it is important to make sure to propagate routing + information for both directions in backup situations like this. + Connectivity in just one direction is not useful at all for almost + all applications. + + Note also that in case the AS6-AS123 connection breaks, AS6 will only + be able to talk to AS4. The symmetrical case (5d) is left as an + exercise to the reader. + +10. Future Extensions + + We envision that over time the requirements for describing routing + policy will evolve. The routing protocols will evolve to support the + requirements and the routing policy description syntax will need to + evolve as well. For that purpose, a separate document will describe + experimental syntax definitions for policy description. This + document [14] will be updated when new objects or attributes are + proposed or modified. + + + +Bates, et al. [Page 50] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +11. References + + [1] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P., + Terpstra, M., "Representation of IP Routing Policies in the RIPE + Database", RIPE-81, February 1993. + + [2] Merit Network Inc.,"Representation of Complex Routing Policies + of an Autonomous System", Work in Progress, March 1994. + + [3] PRIDE Tools Release 1. + See ftp.ripe.net:pride/tools/pride-tools-1.tar.Z. + + [4] Merit Inc. RRDB Tools. + See rrdb.merit.edu:pub/meritrr/* + + [5] The Network List Compiler. + See dxcoms.cern.ch:pub/ripe-routing-wg/nlc-2.2d.tar + + [6] Lord, A., Terpstra, M., "RIPE Database Template for Networks and + Persons", RIPE-119, October 1994. + + [7] Karrenberg, D., "RIPE Database Template for Domains", RIPE-49, + April 1992. + + [8] Lougheed, K., Rekhter, Y., "A Border Gateway Protocol 3 (BGP- + 3)", RFC1267, October 1991. + + [9] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", + RFC-1654, May 1994. + + [10] Bates, T., Karrenberg, D., Terpstra, M., "Support for Classless + Internet Addresses in the RIPE Database", RIPE-121, October + 1994. + + [11] Karrenberg, D., "Authorisation and Notification of Changes in + the RIPE Database", RIPE-120, October 1994. + + [12] Bates, T., "Support of Guarded fields within the RIPE Database", + ripe-117, July 1994. + + [13] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., Zappala, D., + "Source Demand Routing: Packet Format and Forwarding + Specification (Version 1)", Work in Progress, March 1994. + + [14] Joncheray, L., "Experimental Objects and attributes for the + Routing Registry", RIPE-182, October1994. + + [15] Bates, T., "Specifying an `Internet Router' in the Routing + + + +Bates, et al. [Page 51] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Registry", RIPE-122, October 1994. + + [16] Bates, T., Karrenberg, D., Terpstra, M., "RIPE Database + Transition Plan", RIPE-123, October 1994. + +12. Security Considerations + + Security issues are beyond the scope of this memo. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 52] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +13. Authors' Addresses + + + Tony Bates + MCI Telecommunications Corporation + 2100 Reston Parkway + Reston, VA 22094 + USA + +1 703 715 7521 + Tony.Bates@mci.net + + + Elise Gerich + The University of Michigan + Merit Computer Network + 1075 Beal Avenue + Ann Arbor, MI 48109 + USA + +1 313 936 2120 + epg@merit.edu + + + Laurent Joncheray + The University of Michigan + Merit Computer Network + 1075 Beal Avenue + Ann Arbor, MI 48109 + USA + +1 313 936 2065 + lpj@merit.edu + + + Jean-Michel Jouanigot + CERN, European Laboratory for Particle Physics + CH-1211 Geneva 23 + Switzerland + +41 22 767 4417 + Jean-Michel.Jouanigot@cern.ch + + + Daniel Karrenberg + RIPE Network Coordination Centre + Kruislaan 409 + NL-1098 SJ Amsterdam + The Netherlands + +31 20 592 5065 + D.Karrenberg@ripe.net + + + + +Bates, et al. [Page 53] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + + Marten Terpstra + Bay Networks, Inc. + 2 Federal St + Billerica, MA 01821 + USA + +1 508 436 8036 + marten@BayNetworks.com + + + Jessica Yu + The University of Michigan + Merit Computer Network + 1075 Beal Avenue + Ann Arbor, MI 48109 + USA + +1 313 936 2655 + jyy@merit.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 54] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +Appendix A - Syntax for the aut-num object. + + Here is a summary of the tags associated with aut-num object itself + and their status. The first column specifies the attribute, the + second column whether this attribute is mandatory in the aut-num + object, and the third column whether this specific attribute can + occur only once per object [single], or more than once [multiple]. + When specifying multiple lines per attribute, the attribute name must + be repeated. See [6] the example for the descr: attribute. + + + aut-num: [mandatory] [single] + as-name: [optional] [single] + descr: [mandatory] [multiple] + as-in: [optional] [multiple] + as-out: [optional] [multiple] + interas-in: [optional] [multiple] + interas-out: [optional] [multiple] + as-exclude: [optional] [multiple] + default: [optional] [multiple] + tech-c: [mandatory] [multiple] + admin-c: [mandatory] [multiple] + guardian: [mandatory] [single] + remarks: [optional] [multiple] + notify: [optional] [multiple] + mnt-by: [optional] [multiple] + changed: [mandatory] [multiple] + source: [mandatory] [single] + + + Each attribute has the following syntax: + + + aut-num: + The autonomous system number. This must be a uniquely allocated + autonomous system number from an AS registry (i.e. the RIPE NCC, + the Inter-NIC, etc). + + Format: + AS + + Example: + + aut-num: AS1104 + + Status: mandatory, only one line allowed + + + + + +Bates, et al. [Page 55] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +as-name: + The name associated with this AS. This should as short but as + informative as possible. + + Format: + Text consisting of capitals, dashes ("-") and digits, but must + start with a capital. + + Example: + + as-name: NIKHEF-H + + Status: single, only one line allowed + +descr: + A short description of the Autonomous System. + + Format: + free text + + Example: + + descr: NIKHEF section H + descr: Science Park Watergraafsmeer + descr: Amsterdam + + Status: mandatory, multiple lines allowed + +as-in: + A description of accepted routing information between AS peers. + + Format: + from accept + + The keywords from and accept are optional and can be omitted. + + refers to your AS neighbor. + + is a positive integer used to express a relative cost + of routes learned. The lower the cost the more preferred the + route. + + can take the following formats. + + 1. A list of one or more ASes, AS Macros, Communities or + Route Lists. + + A Route List is a list of routes in prefix length format, + + + +Bates, et al. [Page 56] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + separated by commas, and surrounded by curly brackets + (braces, i.e. `{' and '}'). + + + Examples: + + as-in: from AS1103 100 accept AS1103 + as-in: from AS786 105 accept AS1103 + as-in: from AS786 10 accept AS786 HEPNET + as-in: from AS1755 110 accept AS1103 AS786 + as-in: from AS3333 100 accept {192.87.45.0/16} + + + 2. A set of KEYWORDS. The following KEYWORD is currently + defined: + + + ANY this means anything the neighbor AS knows. + + 3. A logical expression of either 1 or 2 above The current + logical operators are defined as: + + AND + OR + NOT + + This operators are defined as true BOOLEAN operators even + if the operands themselves do not appear to be BOOLEAN. + Their operations are defined as follows: + + Operator Operation Example + + OR UNION AS1 OR AS2 + | + +-> all routes in AS1 + or AS2. + + AND INTERSECTION AS1 AND HEPNET + | + +-> a route in AS1 and + belonging to + community HEPNET. + + NOT COMPLEMENT NOT AS3 + | + +-> any route except + AS3 routes. + + + + +Bates, et al. [Page 57] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Rules are grouped together using parenthesis i.e "(" and + ")". + + The ordering of evaluation of operators and there + association is as follows: + + Operator Associativity + + () left to right + NOT right to left + AND left to right + OR left to right + + + NOTE: if no logical operator is given between ASes, AS- + macros, Communities, Route Lists and KEYWORDS it is + implicitly evaluated as an `OR' operation. The OR can be + left out for conciseness. However, please note the + operators are still evaluated as below so make sure you + include parentheses whenever needed. To highlight this + here is a simple example. If we denoted a policy of for + example; from AS1755 I accept all routes except routes + from AS1, A2 and AS3 and you enter the following as-in + line. + + + as-in: from AS1755 100 accept NOT AS1 AS2 AS3 + + + This will be evaluated as: + + + as-in: from AS1755 100 accept NOT AS1 OR AS2 OR AS3 + + + Which in turn would be evaluated like this: + + (NOT AS1) OR AS2 OR AS3 + -> ((ANY except AS1) union AS2) union AS3) + --> (ANY except AS1) + + This is clearly incorrect and not the desired result. The + correct syntax should be: + + + as-in: from AS1755 100 accept NOT (AS1 AS2 AS3) + + + + + +Bates, et al. [Page 58] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Producing the following evaluation: + + + NOT (AS1 OR AS2 OR AS3) + -> (ANY) except (union of AS1, AS2, AS3) + + + Which depicts the desired routing policy. + Note that can also be written as below which is perhaps + somewhat clearer: + + + as-in: from AS1755 100 accept ANY AND NOT + as-in: from AS1755 100 accept (AS1 OR AS2 OR AS3) + + + Examples: + + as-in: from AS1755 100 accept ANY AND NOT (AS1234 OR AS513) + as-in: from AS1755 150 accept AS1234 OR {35.0.0.0/8} + + A rule can be wrapped over lines providing the associated + , values and from and accept keywords are + repeated and occur on consecutive lines. + + Example: + + as-in: from AS1755 100 accept ANY AND NOT (AS1234 AS513) + + and + + as-in: from AS1755 100 accept ANY AND NOT ( + as-in: from AS1755 100 accept AS1234 AS513) + + are evaluated to the same result. Please note that the + ordering of these continuing lines is significant. + + Status: optional, multiple lines allowed + + + + + + + + + + + + + +Bates, et al. [Page 59] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +as-out: + A description of generated routing information sent to other AS + peers. + + Format: + to announce refers to your AS neighbor. + + is explained in the as-in + attribute definition above. + + Example: + + as-out: to AS1104 announce AS978 + as-out: to AS1755 announce ANY + as-out: to AS786 announce ANY AND NOT (AS978) + + Status: optional, multiple lines allowed + +interas-in: + Describes incoming local preferences on an inter AS connection. + + Format: + from accept + + + The keywords from and accept are optional and can be omitted. + + is an autonomous system as defined in as-in. + + contains the IP address of the border router in + the AS describing the policy. IP address must be in prefix + length format. + + contains the IP address of neighbor AS's border + router from which this AS accept routes defined in the + . IP addresses must be in prefix + length format. + + is defined as follows: + + (=) + + It should be noted the parenthesis "(" and ")" and the + "" keyword must be present for this preference to + + + +Bates, et al. [Page 60] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + be valid. + + currently only supports "pref". It could be + expanded to other type of preference such as TOS/QOS as + routing technology matures. + + can take one of the following values: + + + is a positive integer used to express a relative + cost of routes learned. The lower the cost the more + preferred the route. This value is only comparable + to other interas-in attributes, not to as-in attributes. + + MED + This indicates the AS will use the + MUTLI_EXIT_DISCRIMINATOR (MED) metric, as implemented in + BGP4 and IDRP, sent from its neighbor AS. + + NOTE: Combinations of MED and should be avoided + for the same destinations. + + CAVEAT: The pref-type values may well be enhanced in the + future as more inter-ASs routing protocols introduce + other metrics. + + Any route specified in interas-in and not specified in + as-in is assumed not accepted between the ASes concerned. + Diagnostic tools should flag this inconsistency as an + error. It should be noted that if an interas-in policy + is specified then it is mandatory to specify the + corresponding global policy in the as-in line. Please + note there is no relevance in the cost associated with + as-in and the preferences used in interas-in. + is an expression as defined in + as-in above. + + Examples: + + NB: This line is wrapped for readability. + interas-in: from AS1104 192.(pref=10)/accept.AS786.AS987 + interas-in: from AS1104 192.87.45.(pref=20)2accept.AS987 + interas-in: from AS1103 192.87.45.2(pref=MED)8accept2ANY + + Status: optional, multiple lines allowed + + + + + + +Bates, et al. [Page 61] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +interas-out: + + Format: + to [] announce + + + The keywords to and announce are optional and can be omitted. + + The definitions of , , and + are identical to those defined in + interas-in. + + is optional and is defined as follows: + + (=) + + It should be noted the parenthesis "(" and ")" and the + keywords of "" must be present for this metric to + be valid. + + currently only supports "metric-out". It could + be expanded to other type of preference such as TOS/QOS as + routing technology matures. + can take one of the following values: + + + is a pre-configured metric for out-bound + routes. The lower the cost the more preferred the route. + This value is literally passed by the + routing protocol to the neighbor. It is expected that it + is used there which is indicated by pref=MED on the + corresponding interas-in attribute. It should be noted + that whether to accept the outgoing metric or not is + totally within the discretion of the neighbor AS. + + IGP + This indicates that the metric reflects the ASs internal + topology cost. The topology is reflected here by using + MED which is derived from the AS's IGP metric. + + NOTE: Combinations of IGP and should be + avoided for the same destinations. + + CAVEAT: The metric-out values may well be enhanced in the + future as more interas protocols make use of metrics. + + Any route specified in interas-out and not specified in + as-out is assumed not announced between the ASes + + + +Bates, et al. [Page 62] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + concerned. Diagnostic tools should flag this + inconsistency as an error. It should be noted that if an + interas-out policy is specified then it is mandatory to + specify the corresponding global policy in the as-out + line. + + Examples: + + interas-out:ntoiAS1104p192.87.45.254/32t192.87.45.80/32 + interas-out: to AS1104m192.87.45.254/32n192.87.45.80/32 + interas-out: to AS1103 192.87.45.254/325192.87.45.80/32 + (metric-out=IGP) announce ANY + + Status: optional, multiple lines allowed + +as-exclude: + A list of transit ASes to ignore all routes from. + + Format: + exclude to + + Keywords exclude and to are optional and can again be omitted. + + refers to the transit AS in question. + + an can be ONE of the following. + + 1. + + 2. AS macro + + 3. Community + + 4. ANY + + Examples: + + as-exclude: exclude AS690 to HEPNET + + This means exclude any HEPNET routes which have a route via + AS690. + + as-exclude: exclude AS1800 to AS-EUNET + + This means exclude any AS-EUNET routes which have a route via + AS1800. + + as-exclude: exclude AS1755 to AS1104 + + + +Bates, et al. [Page 63] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + This means exclude any AS1104 route which have a route via + AS1755. + + as-exclude: exclude AS1104 to ANY + + This means exclude all routes which have a route via AS1104. + + Status: optional, multiple lines allowed + +default: + An indication of how default routing is done. + + Format: + + + where is the AS peer you will default route to, + + and is the relative cost is a positive integer + used to express a preference for default. There is no + relationship to the cost used in the as-in tag. The AS peer + with the lowest cost is used for default over ones with higher + costs. + + is optional and provides information on + how a default route is selected. It can take the following + formats: + + 1. static. This indicates that a default is statically + configured to this AS peer. + + 2. A route list with the syntax as described in the as-in + attribute. This indicates that this list of routes is + used to generate a default route. A special but valid + value in this is the special route used by some routing + protocols to indicate default: 0.0.0.0/0 + + 3. default. This is the same as {0.0.0.0/0}. This means that + the routing protocol between these two peers generates a + true default. + + Examples: + + default: AS1755 10 + default: AS786 5 {140.222.0.0/16, 192.87.45.0/24} + default: AS2043 15 default + + Status: optional, multiple lines allowed + + + + +Bates, et al. [Page 64] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +tech-c: + Full name or uniquely assigned NIC-handle of a technical contact + person. This is someone to be contacted for technical problems such + as misconfiguration. + + Format: + or + + Example: + + tech-c: John E Doe + tech-c: JED31 + + Status: mandatory, multiple lines allowed + +admin-c: + Full name or uniquely assigned NIC-handle of an administrative + contact person. In many cases this would be the name of the + guardian. + + Format: + or + + Example: + + admin-c: Joe T Bloggs + admin-c: JTB1 + + Status: mandatory, multiple lines allowed + +guardian: + Mailbox of the guardian of the Autonomous system. + + Format: + + + The should be in RFC822 domain format wherever + possible. + + Example: + + guardian: as1104-guardian@nikhef.nl + + Status: mandatory, only one line and e-mail address allowed + + + + + + + +Bates, et al. [Page 65] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +remarks: + Remarks/comments, to be used only for clarification. + + Format: + free text + + Example: + + remarks: Multihomed AS talking to AS1755 and AS786 + remarks: Will soon connect to AS1104 also. + + Status: optional, multiple lines allowed + +notify: + The notify attribute contains an email address to which + notifications of changes to this object should be sent. See also + [11]. + + Format: + + + The should be in RFC822 domain syntax wherever + possible. + + Example: + + notify: Marten.Terpstra@ripe.net + + Status: optional, multiple lines allowed + +mnt-by: + The mnt-by attribute contains a registered maintainer name. See + also [11]. + + Format: + + + Example: + + mnt-by: RIPE-DBM + + Status: optional, multiple lines allowed + +changed: + Who changed this object last, and when was this change made. + + Format: + YYMMDD + + + +Bates, et al. [Page 66] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + should be the address of the person who made + the last change. YYMMDD denotes the date this change was made. + + Example: + + changed: johndoe@terabit-labs.nn 900401 + + Status: mandatory, multiple lines allowed + +source: + Source of the information. + + This is used to separate information from different sources kept by + the same database software. For RIPE database entries the value is + fixed to RIPE. + + Format: + RIPE + Status: mandatory, only one line allowed + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 67] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +Appendix B - Syntax details for the community object. + + Here is a summary of the tags associated with community object itself + and their status. The first column specifies the attribute, the + second column whether this attribute is mandatory in the community + object, and the third column whether this specific attribute can + occur only once per object [single], or more than once [multiple]. + When specifying multiple lines per attribute, the attribute name must + be repeated. See [6] the example for the descr: attribute. + + + community: [mandatory] [single] + descr: [mandatory] [multiple] + authority: [mandatory] [single] + guardian: [mandatory] [single] + tech-c: [mandatory] [multiple] + admin-c: [mandatory] [multiple] + remarks: [optional] [multiple] + notify: [optional] [multiple] + mnt-by: [optional] [multiple] + changed: [mandatory] [multiple] + source: [mandatory] [single] + + + Each attribute has the following syntax: + + + community: + Name of the community. The name of the community should be + descriptive of the community it describes. + + Format: + Upper case text string which cannot start with "AS" or any + of the KEYWORDS. See Appendix + A. + + Example: + + community: WCW + + Status: mandatory, only one line allowed + + + + + + + + + + +Bates, et al. [Page 68] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + descr: + A short description of the community represented. + + Format: + free text + + Example: + + descr: Science Park Watergraafsmeer + descr: Amsterdam + + Status: mandatory, multiple lines allowed + + authority: + The formal authority for this community. This could be an + organisation, institute, committee, etc. + + Format: + free text + + Example: + + authority: WCW LAN Committee + + Status: mandatory, only one line allowed + + guardian: + Mailbox of the guardian of the community. + + Format: + + + The should be in RFC822 domain format + wherever possible. + + Example: + + guardian: wcw-guardian@nikhef.nl + + Status: mandatory, only one line and email address allowed + + tech-c: + Full name or uniquely assigned NIC-handle of an technical + contact person for this community. + + + + + + + +Bates, et al. [Page 69] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Format: + or + + Example: + + tech-c: John E Doe + tech-c: JED31 + + Status: mandatory, multiple lines allowed + + admin-c: + Full name or uniquely assigned NIC-handle of an administrative + contact person. In many cases this would be the name of the + guardian. + + Format: + or + + Example: + + admin-c: Joe T Bloggs + admin-c: JTB1 + + Status: mandatory, multiple lines allowed + + remarks: + Remarks/comments, to be used only for clarification. + + Format: + free text + + Example: + + remarks: Temporary community + remarks: Will be removed after split into ASes + + Status: optional, multiple lines allowed + + notify: + The notify attribute contains an email address to which + notifications of changes to this object should be send. See also + [11]. + + Format: + + + The should be in RFC822 domain syntax + wherever possible. + + + +Bates, et al. [Page 70] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Example: + + notify: Marten.Terpstra@ripe.net + + Status: optional, multiple lines allowed + + mnt-by: + The mnt-by attribute contains a registered maintainer name. See + also [11]. + + Format: + + + Example: + + mnt-by: RIPE-DBM + + Status: optional, multiple lines allowed + + changed: + Who changed this object last, and when was this change made. + + Format: + YYMMDD + + should be the address of the person who + made the last change. YYMMDD denotes the date this change + was made. + + Example: + + changed: johndoe@terabit-labs.nn 900401 + + Status: mandatory, multiple lines allowed + + source: + Source of the information. + + This is used to separate information from different sources kept + by the same database software. For RIPE database entries the + value is fixed to RIPE. + + Format: + RIPE + Status: mandatory, only one line allowed + + + + + + +Bates, et al. [Page 71] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +Appendix C - AS Macros syntax definition. + + Here is a summary of the tags associated with as-macro object itself + and their status. The first column specifies the attribute, the + second column whether this attribute is mandatory in the as-macro + object, and the third column whether this specific attribute can + occur only once per object [single], or more than once [multiple]. + When specifying multiple lines per attribute, the attribute name must + be repeated. See [6] the example for the descr: attribute. + + + as-macro: [mandatory] [single] + descr: [mandatory] [multiple] + as-list: [mandatory] [multiple] + guardian: [mandatory] [single] + tech-c: [mandatory] [multiple] + admin-c: [mandatory] [multiple] + remarks: [optional] [multiple] + notify: [optional] [multiple] + mnt-by: [optional] [multiple] + changed: [mandatory] [multiple] + source: [mandatory] [single] + + + Each attribute has the following syntax: + + + as-macro: + The name of a macro containing at least two Autonomous Systems + grouped together for ease of administration. + + Format: + AS- + + The should be in upper case and not contain any + special characters. + + Example: + + as-macro: AS-EBONE + + Status: mandatory, only one line allowed + + descr: + A short description of the Autonomous System Macro. + + Format: + free text + + + +Bates, et al. [Page 72] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Example: + + descr: Macro for EBONE connected ASes + + Status: mandatory, multiple lines allowed + + as-list: + The list of ASes or other AS macros that make up this macro. It + should be noted that recursive use of AS macros is to be + encouraged. + + Format: + ... + + See Appendix A for definition. + + Example: + + as-list: AS786 AS513 AS1104 + as-list: AS99 AS-NORDUNET + + Status: mandatory, multiple lines allowed + + guardian: + Mailbox of the guardian of this AS macro. + + Format: + + + The should be in RFC822 domain format + wherever possible. + + Example: + + guardian: as-ebone-guardian@ebone.net + + Status: mandatory, only one line and e-mail address allowed + + tech-c: + Full name or uniquely assigned NIC-handle of a technical contact + person for this macro. This is someone to be contacted for + technical problems such as misconfiguration. + + Format: + or + + + + + + +Bates, et al. [Page 73] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Examples: + + tech-c: John E Doe + tech-c: JED31 + + Status: mandatory, multiple lines allowed + + admin-c: + Full name or uniquely assigned NIC-handle of an administrative + contact person. In many cases this would be the name of the + guardian. + + Format: + or + + Examples: + + admin-c: Joe T Bloggs + admin-c: JTB1 + + Status: mandatory, multiple lines allowed + + remarks: + Remarks/comments, to be used only for clarification. + + Format: + free text + + Example: + + remarks: AS321 will be removed from this Macro shortly + + Status: optional, multiple lines allowed + + notify: + The notify attribute contains an email address to which + notifications of changes to this object should be send. See also + [11]. + + Format: + + + The should be in RFC822 domain syntax + wherever possible. + + Example: + + notify: Marten.Terpstra@ripe.net + + + +Bates, et al. [Page 74] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Status: optional, multiple lines allowed + + mnt-by: + The mnt-by attribute contains a registered maintainer name. See + also [11]. + + Format: + + + Example: + + mnt-by: RIPE-DBM + + Status: optional, multiple lines allowed + + changed: + Who changed this object last, and when was this change made. + + Format: + YYMMDD + + should be the address of the person who + made the last change. YYMMDD denotes the date this change + was made. + + Example: + + changed: johndoe@terabit-labs.nn 900401 + + Status: mandatory, multiple lines allowed + + source: + Source of the information. + + This is used to separate information from different sources kept + by the same database software. For RIPE database entries the + value is fixed to RIPE. + + Format: + RIPE + Status: mandatory, only one line allowed + + + + + + + + + + +Bates, et al. [Page 75] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +Appendix D - Syntax for the "route" object. + + There is a summary of the tags associated with route object itself + and their status. The first column specifies the attribute, the + second column whether this attribute is mandatory in the community + object, and the third column whether this specific attribute can + occur only once per object [single], or more than once [multiple]. + When specifying multiple lines per attribute, the attribute name must + be repeated. See [6] the example for the descr: attribute. + + + route: [mandatory] [single] + descr: [mandatory] [multiple] + origin: [mandatory] [single] + hole: [optional] [multiple] + withdrawn: [optional] [single] + comm-list: [optional] [multiple] + remarks: [optional] [multiple] + notify: [optional] [multiple] + mnt-by: [optional] [multiple] + changed: [mandatory] [multiple] + source: [mandatory] [single] + + + Each attribute has the following syntax: + + + route: + Route being announced. + + Format: + Classless representation of a route with the RIPE database + known as the "prefix length" representation. See [10] for + more details on classless representations. + + Examples: + + route: 192.87.45.0/24 + + This represents addressable bits 192.87.45.0 to + 192.87.45.255. + + route: 192.1.128.0/17 + + This represents addressable bits 192.1.128.0 to + 192.1.255.255. + + Status: mandatory, only one line allowed + + + +Bates, et al. [Page 76] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + origin: + The autonomous system announcing this route. + + Format: + + + See Appendix A for syntax. + + Example: + + origin: AS1104 + + Status: mandatory, only one line allowed + + hole: + Denote the parts of the address space covered this route object + to which the originator does not provide connectivity. These + holes may include routes that are being currently routed by + another provider (e.g., a customer using that space has moved to + a different service provider). They may also include space that + has not yet been assigned to any customer. + + Format: + Classless representation of a route with the RIPE database + known as the "prefix length" representation. See [10] for + more details on classless representations. It should be + noted that this sub-aggregate must be a component of that + registered in the route object. + + Example: + + hole: 193.0.4.0/24 + + Status: optional, multiple lines allowed + + withdrawn: + Used to denote the day this route has been withdrawn from the + Internet routing mesh. This will be usually be used when a less + specific aggregate route is now routed the more specific (i.e. + this route) is not need anymore. + + Format: + YYMMDD + + YYMMDD denotes the date this route was withdrawn. + + + + + + +Bates, et al. [Page 77] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Example: + + withdrawn: 940711 + + Status: optional, one line allowed. + + comm-list: + List of one or more communities this route is part of. + + Format: + ... + + See Appendix B for definition. + + Example: + + comm-list: HEP LEP + + Status: optional, multiple lines allowed + + remarks: + Remarks/comments, to be used only for clarification. + + Format: + free text + + Example: + + remarks: Multihomed AS talking to AS1755 and AS786 + remarks: Will soon connect to AS1104 also. + + Status: optional, multiple lines allowed + + notify: + The notify attribute contains an email address to which + notifications of changes to this object should be send. See also + [11]. + + Format: + + + The should be in RFC822 domain syntax + wherever possible. + + Example: + + notify: Marten.Terpstra@ripe.net + + + + +Bates, et al. [Page 78] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Status: optional, multiple lines allowed + + mnt-by: + The mnt-by attribute contains a registered maintainer name. See + also [11]. + + Format: + + + Example: + + mnt-by: RIPE-DBM + + Status: optional, multiple lines allowed + + changed: + Who changed this object last, and when was this change made. + + Format: + YYMMDD + + should be the address of the person who + made the last change. YYMMDD denotes the date this change + was made. + + Example: + + changed: johndoe@terabit-labs.nn 900401 + + Status: mandatory, multiple lines allowed + + source: + Source of the information. + + This is used to separate information from different sources kept + by the same database software. For RIPE database entries the + value is fixed to RIPE. + + Format: + RIPE + Status: mandatory, only one line allowed + + + + + + + + + + +Bates, et al. [Page 79] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +Appendix E - List of reserved words + + The following list of words are reserved for use within the + attributes of the AS object. The use of these words is solely for the + purpose of clarity. All keywords must be lower case. + + + accept + announce + exclude + from + to + transit + + + Examples of the usage of the reserved words are: + + as-in: from accept + + as-out: to announce + + as-exclude: exclude to + + as-transit: transit to + + default: from accept + + default: to announce + + + Note: that as-transit is an experimental attribute. See section 10. + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 80] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +Appendix F - Motivations for RIPE-81++ + + This appendix gives motivations for the major changes in this + proposal from ripe-81. + + The main goals of the routing registry rework are: + + + SPLIT + Separate the allocation and routing registry functions into + different database objects. This will facilitate data management + if the Internet registry and routing registry functions are + separated (like in other parts of the world). It will also make + more clear what is part of the routing registry and who has + authority to change allocation vs. routing data. + + + CIDR + Add the possibility to specify classless routes in the routing + registry. Classless routes are being used in Internet + production now. Aggregation information in the routing registry + is necessary for network layer troubleshooting. It is also + necessary because aggregation influences routing policies + directly. + + + CALLOC + Add the possibility to allocate address space on classless + boundaries in the allocation registry. This is a way to preserve + address space. + + + CLEAN + To clean up some of the obsolete and unused parts of the routing + registry. + + + The major changes are now discussed in turn: + + + Introduce Classless Addresses + + CIDR, CALLOC + + + Introduce route object. + + SPLIT, CIDR and CALLOC. + + + +Bates, et al. [Page 81] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + + Delete obsolete attributes from inetnum. + + CLEAN. + + + Delete RIPE-DB and LOCAL from routing policy expressions. + + CLEAN + + + Allow multiple ASes to originate the same route + + Because it is being done. CIDR. Made possible by SPLIT. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 82] + +RFC 1786 Representing IP Routing Policies in a RR March 1995 + + +Appendix G - Transition strategy from RIPE-81 to RIPE-81++ + +Transition from the routing registry described by ripe-81 to the routing +registry described in this document is a straightforward process once +the new registry functions have been implemented in the database +software and are understood by the most commonly used registry tools. +The routing related attributes in the classful inetnum objects of ripe- +81 can be directly translated into new routing objects. Then these +attributes can be deleted from the inetnum object making that object if +conform to the new schema. + +Proposed transition steps: + + + 1) Implement classless addresses and new object definition in the + database software. + + + 2) Make common tools understand the new schema and prefer it if both + old and new are present. + + + 3) Invite everyone to convert their data to the new format. This can + be encouraged by doing conversions automatically and proposing them + to maintainers. + + + 4) At a flag day remove all remaining routing information from the + inetnum objects. Before the flag day all usage of obsoleted + inetnum attributes has to cease and all other routing registry + functions have to be taken over by the new objects and attributes. + + + + + + + + + + + + + + + + + + + + +Bates, et al. [Page 83] + \ No newline at end of file -- cgit v1.2.3