GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1786

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 <routing policy expressions> 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
 <further neighbors>
 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
 <further neighbors>

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
 <further neighbors>
 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
 <further neighbors>
 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
 <further neighbors>
 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
 <further neighbors>
 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
 <further neighbors>
 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<positive integer between 1 and 65535>
      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 <aut-num> <cost> accept <routing policy expression>
        The keywords from and accept are optional and can be omitted.
        <aut-num> refers to your AS neighbor.
        <cost> is a positive integer used to express a relative cost
        of routes learned. The lower the cost the more preferred the
        route.
        <routing policy expression> 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
        <aut-num>, <cost> 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 <aut-num> announce <routing policy expression
        The to and announce keywords are optional and can be omitted.
        <aut-num> refers to your AS neighbor.
        <routing policy expression> 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 <aut-num> <local-rid> <neighbor-rid> <preference> accept
        <routing policy expression>
        The keywords from and accept are optional and can be omitted.
        <aut-num> is an autonomous system as defined in as-in.
        <local-rid> contains the IP address of the border router in
        the AS describing the policy.  IP address must be in prefix
        length format.
        <neighbor-rid> contains the IP address of neighbor AS's border
        router from which this AS accept routes defined in the
        <routing policy expression>.  IP addresses must be in prefix
        length format.
        <preference> is defined as follows:
        (<pref-type>=<value>)
        It should be noted the parenthesis "(" and ")" and the
        "<pref-type>" 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.
        <pref-type> currently only supports "pref".  It could be
        expanded to other type of preference such as TOS/QOS as
        routing technology matures.
        <value> can take one of the following values:
        <cost>
             <cost> is a positive integer used to express a relative
             cost of routes learned. The lower the cost the more
             preferred the route. This <cost> 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 <cost> 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.
        <routing policy expression> 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 <aut-num> <local-rid> <neighbor-rid> [<metric>] announce
        <routing policy expression>
        The keywords to and announce are optional and can be omitted.
        The definitions of <aut-num>, <local-rid> <neighbor-rid>, and
        <routing policy expression> are identical to those defined in
        interas-in.
        <metric> is optional and is defined as follows:
        (<metric-type>=<value>)
        It should be noted the parenthesis "(" and ")" and the
        keywords of "<metric-type>" must be present for this metric to
        be valid.
        <metric-type> currently only supports "metric-out".  It could
        be expanded to other type of preference such as TOS/QOS as
        routing technology matures.
        <value> can take one of the following values:
        <num-metric>
             <num-metric> is a pre-configured metric for out-bound
             routes. The lower the cost the more preferred the route.
             This <num-metric> 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 <num-metric> 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 <aut-num> to <exclude-route-keyword>
        Keywords exclude and to are optional and can again be omitted.
        <aut-num> refers to the transit AS in question.
        an <exclude-route-keyword> can be ONE of the following.
        1.   <aut-num>
        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:
        <aut-num> <relative cost> <default-expression>
        where <aut-num> is the AS peer you will default route to,
        and <relative cost> 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.
        <default-expression> 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:
        <firstname> <initials> <lastname> or <nic-handle>
   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:
        <firstname> <initials> <lastname>  or  <nic-handle>
   Example:
        admin-c: Joe T Bloggs
        admin-c: JTB1
   Status: mandatory, multiple lines allowed

guardian:

   Mailbox of the guardian of the Autonomous system.
   Format:
        <email-address>
        The <email-address> 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:
        <email-address>
        The <email-address> 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:
        <registered maintainer name>
   Example:
        mnt-by: RIPE-DBM
   Status: optional, multiple lines allowed

changed:

   Who changed this object last, and when was this change made.
   Format:
        <email-address> YYMMDD

Bates, et al. [Page 66] RFC 1786 Representing IP Routing Policies in a RR March 1995

        <email-address> 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 <routing policy expression> 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:
           <email-address>
           The <email-address> 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:
           <firstname> <initials> <lastname> or <nic-handle>
      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:
           <firstname> <initials> <lastname> or <nic-handle>
      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:
           <email-address>
           The <email-address> 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:
           <registered maintainer name>
      Example:
           mnt-by: RIPE-DBM
      Status: optional, multiple lines allowed
 changed:
      Who changed this object last, and when was this change made.
      Format:
           <email-address> YYMMDD
           <email-address> 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-<string>
           The <string> 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:
           <aut-num> <as-macro> ...
           See Appendix A for <aut-num> 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:
           <email-address>
           The <email-address> 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:
           <firstname> <initials> <lastname> or <nic-handle>

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:
           <firstname> <initials> <lastname> or <nic-handle>
      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:
           <email-address>
           The <email-address> 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:
           <registered maintainer name>
      Example:
           mnt-by: RIPE-DBM
      Status: optional, multiple lines allowed
 changed:
      Who changed this object last, and when was this change made.
      Format:
           <email-address> YYMMDD
           <email-address> 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:
           <aut-num>
           See Appendix A for <aut-num> 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:
           <community> <community> ...
           See Appendix B for <community> 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:
           <email-address>
           The <email-address> 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:
           <registered maintainer name>
      Example:
           mnt-by: RIPE-DBM
      Status: optional, multiple lines allowed
 changed:
      Who changed this object last, and when was this change made.
      Format:
           <email-address> YYMMDD
           <email-address> 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 <neighborAS> accept <route>
 as-out: to <neighborAS> announce <route>
 as-exclude: exclude <ASpath> to <destination>
 as-transit: transit <ASpath> to <destination>
 default: from <neighborAS> accept <route>
 default: to <neighborAS> announce <route>
 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1786.txt · Last modified: 1995/03/21 22:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki