Introduction to the InternetMCI Routing Registry DRAFT * DRAFT * DRAFT November 29th, 1994 Tony Bates Table of Contents 1 Introduction ................................................ 2 2 The Basic Model ............................................. 2 3 The RR Objects .............................................. 4 3.1 The "route" Object ........................................ 4 3.2 The "aut-num" Object ...................................... 5 3.3 The "mntner" Object ....................................... 7 3.4 Other Objects ............................................. 7 4 Querying the RR ............................................. 8 5 References .................................................. 10 Appendix A - Syntax for the "route" object .................... 11 Appendix B - Syntax for the aut-num object .................... 14 _________________________ This work was carried out under contract to MCI. Tony Bates is a member of the RARE/RIPE PRIDE project located in Amsterdam, The Netherlands. MCI Confidential 1 DRAFT Appendix C - AS Macros syntax definition ...................... 24 Appendix D - Syntax for the "mntner" object ................... 27 MCI Confidential 2 DRAFT 1. Introduction This document outlines a basic overview of the InternetMCI Routing Registry (RR) now referred to as the RR. The RR is a key component of the InternetMCI service and all customers need to be aware of it existence and use. An RR is simply a repository of routing informa- tion which can be used as both information for configuration genera- tion and problem diagnosis. This document should be read in conjunction with the companion user guide [4]. The InternetMCI RR is based on the current "de-facto" standard for routing registries known as "ripe-81++" and detailed in [1]. It is important to have a full understanding of the representation used within this document. As the InternetMCI RR is based on ripe-81++ this document takes advantage of references to various other docu- ments and specifically the work of the PRIDE project and RIPE. MCI acknowledges and supports the efforts of the PRIDE project team and its work on creating a global routing registry. 2. The Basic Model The RR acts as both the user interface and the router configuration itself. It will allow customers to register, maintain and query routes in the RR database. The way in which the information is stored is in the form of simple objects. Each of these objects has a list of associated attributes which describe all the information needed for a relevant object entity. The objects used are described in some detail below. If we look at how the RR will be used we see two basic components. The first component is the customer update process. This is depicted graphically in Figure 1. Diagram not included in ascii version Figure 1: Customer update component Customers are able to send updates into the RR into one of two ways. Either directly via to the automatic update server or via a human based mailbox. The update and query process sub-components are fur- ther described in [4]. The second component of the RR is the router configuration process. This is shown graphically in figure 2. Diagram not included in ascii version Figure 2: Router configuration component The routing policy information stored in the RR will be used to gen- erate the router configuration files. It is very important that you keep your data up to date and correct at all times as this will MCI Confidential 3 DRAFT directly impact your use or otherwise of the InternetMCI IP network. MCI Confidential 4 DRAFT 3. The RR Objects As stated the data held in the RR will be used to generate configu- ration files. As such it is important that this data is maintained, properly authorized and kept up to date. The data falls into two categories; routing data and maintainance data. Both of these por- tions of data in the RR will be the responsibility of the customer. To gain a basic understanding of how this works we need to look at some simple objects. Once again, please refer to [1] for a full and complete overview of the actual objects themselves. Detailed syntax for each object is given in appendix A to D respectively. This is taken from [1] but is felt useful to have as reference as part of the overview document to be used in conjunction [4] when making real updates and changes to the objects in the RR. 3.1. The "route" Object The route object is perhaps the most crucial object which needs to be register within the InternetMCI RR. The route object describes an IP route as seen in an internet. Below are two examples of route objects, with all possible routing policy description attributes defined: route: 128.167.0.0/16 descr: SURA origin: AS86 comm-list: COMM_NSFNET mnt-by: SURA changed: mci-rr@mci.net 940921 source: MCI route: 204.70.0.0/18 descr: MCI CIDR Block origin: AS3561 withdrawn: 941011 mnt-by: MCI changed: mci-rr@mci.net 941011 source: MCI The combination of the above two route objects contain almost all possible routing policy attributes. In the examples above these are the "origin", "comm-list", "withdrawn" attributes and of course the "route" attribute itself. In addition to the policy attributes there are database control attributes "changed" and "source", a general description attribute "descr" and a special attribute "mnt-by". All except the "changed" and "source" attribute will be described in more detail below. The "route" attribute determines the IP route that is described with this object. It must always be an IP network number in prefix/length notation [2]. In the above cases, an "old" style class B address 128.167.0.0 and a block of 64 class C addresses 204.0.70.0 to 204.0.70.63.0 are described. MCI Confidential 5 DRAFT The "descr" attribute has no policy implications, but is simply a short description of this route. This is because names are generally easier to remember than numbers. The "origin" attribute represents the autonomous system that injects this route into the routing mesh. This autonomous system is gener- ally called the "originating AS" hence the name "origin". The value of this attribute is an AS number, with the letters "AS" prepended. This was mainly done for clarity. In the above examples, the routes are announce by AS86 and AS3561 respectively. The "comm-list" attribute lists the communities this route belongs to. This attribute represents membership of this route to the list of communities mentioned. In the above example, 128.167.0.0/16 is part of the COMM_NSFNET community1. The "mnt-by" attribute is not a routing policy related attribute but must be present in all routes. It represents the maintainer of this object. This maintainer has registered itself in the RR and has listed some authentication meth- ods which have to be met before this object can be updated. More specific details can be found in [3] and the companion document, "The InternetMCI Routing Registry User Guide" [4]. The reason all route object must have a "mnt-by" attribute is that route objects are used in day to day network operations, from trouble shooting to router configuration. Therefore one must be sure that the informa- tion in this object can only be updated by the person responsible for this route. As described above, the "changed" and "source" attributes are database control attributes and do not represent any routing policy information. 3.2. The "aut-num" Object 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. An example AS object could be: _________________________ 1 It should be noted that communities will not be used by the InternetMCI RR initially. MCI Confidential 6 DRAFT aut-num: AS3134 as-name: USAID-ASN descr: U.S. Agency for Internation Development as-in: from AS86 100 accept ANY as-out: to AS86 announce AS3134 interas-in: from AS86 192.221.253.8/32 192.221.253.14/32 (pref=110) accept ANY interas-in: from AS86 192.221.253.8/32 192.221.253.1/32 (pref=100) accept ANY default: AS86 100 {128.167.0.0/16} guardian: nacr@sura.net admin-c: SD3 tech-c: KR11 notify: nacr@sura.net mnt-by: SURA changed: sherk@sura.net 941019 source: MCI In the above example, the attributes are the "as-in", "as-out", "interas-in", interas-out" and "default" attributes and of course the "aut-num" attribute itself. The "aut-num" attributes determines the autonomous system we are describing by this object. Its value is an AS number, again with the letters "AS" prepended for clarity. In the above example, this object describes AS3134. The "as-in" attributes detail the incoming routing policy towards the neighbors of this AS. The syntax of this attribute can be found in [1]. The "as-out" attributes details the outgoing routing policy towards the neighbors of this AS. The syntax of this attribute can also be found in [1]. Likewise for both the "interas-in" and "interas-out" attributes. The "guardian" attribute specifies a mailbox which can be used to report problems network operators may have regarding this AS. The "admin-c" attribute specifies an administrative contact person for this AS. The value is a reference to a person object in the RR database. The "tech-c" attribute specifies a technical contact person for this AS. Also here the value is a reference to a person object in the RR database. The "mnt-by" attribute serves the same purpose as in the "route" object. The "notify", "changed" and "source" attributes are database control attributes and do not specify any routing policy information. The link between an AS object and the routes that are contained within this AS is provided by the "origin" attribute in the route MCI Confidential 7 DRAFT object. The AS macro object describes a set of autonomous systems that can be grouped together for some reason. Most notably the AS macro would be used to group together all autonomous systems that for instance are being served by a single Internet Service provider. The As macro can provide a way to easily address all of these autonomous systems as one entity. This already makes it clear that the AS macro is provided mainly for convenience. This will become even more clear in the next section. An example as-macro object could be: as-macro: AS-SURANET descr: Macro with all ASes SURAnet carries as-list: AS86 AS279 AS3635 AS686 AS1236 AS2532 AS1842 AS3705 as-list: AS3134 AS3461 AS3490 AS225 AS548 AS27 AS3113 AS3135 as-list: AS3134 AS3591 AS2553 AS2637 AS3512 AS2048 AS3450 AS3749 guardian: noc@sura.net tech-c: ES199 admin-c: ES199 mnt-by: SURA changed: mci-rr@mci.net 941011 source: MCI The as-macro object does not specify policy as such, but provides a means of grouping ASes together to be used in policy expressions in an autonomous system object. The "as-macro" attribute itself determines the name of this grouping of ASes. It always starts with "AS-" ends with a descriptive word to specify what this group of ASes stands for. In the example above this macro describes the group of ASes accepted by Big Service Provider The "descr" attribute specifies a short description of what this as- macro represents. The "as-list" attribute simply lists the ASes that make up this macro. An AS-Macro can be used in routing policy expressions for the "as- in" and "as-out" attributes in the AS object. The AS-Macro object is then used to derive the list or group of ASes. 3.3. The "mntner" object The mntner object represents an entity maintaining objects in the RR. The maintainer is identified and referred to by a unique main- tainer name. The mntner object is used every time a RR object with a mnt-by attribute is added, updated or deleted to determine whether the originator of the update request is authorized to make the update. In addition the mntner object provides the same kind of notification ability that is also available with the notify attribute. When MCI Confidential 8 DRAFT using the notify attribute, the user must specify who to notify in every object that he is responsible for. If he wants to change who is notified, every object must be changed. By putting this notifi- cation information in the mntner object, that information is cen- tralized and can be managed more easily. Adding a new mntner object has to be authorized manually by MCI RR staff. Updates to mntner objects follow the normal authorization rules but receive special scrutiny by MCI RR staff. An example mntner object would be as follows: mntner: SURA descr: SURAnet maintainer admin-c: ES199 tech-c: ES199 upd-to: mci-rr@mci.net auth: MAIL-FROM mci-rr@mci.net|.*@sura.net auth: CRYPT-PW fZajrRBtNXeZg notify: mci-rr@mci.net mnt-by: SURA changed: mci-rr@mci.net 941010 source: MCI Please refer to [3] for more precise details of the syntax and usage of the "mntner" object. 3.4. Other Objects The InternetMCI also supports all other objects defined in [1]. How- ever, the current use is limited to the three objects detailed above and the maintainence object "mntner" detailed below which is used for all authorisation and update verification. MCI Confidential 9 DRAFT 4. Querying the RR The basic access mechanism to the RR is through the whois [5] proto- col. The whois interface provides a simple and effective way of querying the database. Each object has a certain number of keys associated with it and using these keys, objects can be retrieved. Typical keys are an IP network number, a network name, an autonomous system number, a community, or a persons first or last name, or NIC handle. Below are some basic examples of whois queries. The queries should be directed to the MCI RR whois server on machine rr.mci.net. This can be achieved using the -h option of whois. Wherever an administrative or technical contact person is referenced, this per- son is also looked up in the database and displayed, as shown below. % whois -h rr.mci.net 204.70.0.0/16 route: 204.70.0.0/16 descr: MCI CIDR Block origin: AS3561 mnt-by: MCI changed: mci-rr@mci.net 941011 source: MCI In the example above a route is queried in the prefix/length format. This is the standard format for whois queries for route objects. The whois server will try and find an exact match for the network number queried. If no exact match is available, the whois server will try and find the first less specific match available in the routing reg- istry. Asking for a host address for instance, would return the net- work or route this host is part of: % whois -h rr.mci.net 204.70.7.0/32 route: 204.70.7.0/30 descr: MCI CPE Loopback origin: AS3561 withdrawn: 941007 mnt-by: MCI mnt-by: MCI changed: roy@mci.net 941007 source: MCI or similar output. In this case the example is a sub-net of the original lookup. Other types of queries or queries for different objects could be: MCI Confidential 10 DRAFT % whois -h rr.mci.net AS279 aut-num: AS279 as-name: ASN-SURANET-2 descr: SURAnet Southern AS as-in: from AS3749 100 accept AS3749 as-in: from AS3512 100 accept AS3512 as-in: from AS3450 100 accept AS3450 as-in: from AS2637 100 accept AS2637 as-in: from AS2048 100 accept AS2048 as-in: from AS690 100 accept ANY as-in: from AS86 100 accept ANY as-out: to AS3749 announce {128.167.0.0/16, 0.0.0.0/0} as-out: to AS3512 announce {128.167.0.0/16, 0.0.0.0/0} as-out: to AS3450 announce {128.167.0.0/16, 0.0.0.0/0} as-out: to AS2637 announce ANY as-out: to AS2048 announce {128.167.0.0/16, 0.0.0.0/0} as-out: to AS690 announce ANY as-out: to AS86 announce ANY interas-in: from AS3749 192.221.52.49/32 192.221.52.50/32 (pref=MED) accept AS3749 interas-in: from AS3749 192.221.8.45/32 192.221.8.46/32 (pref=MED) accept AS3749 interas-in: from AS3749 192.221.51.61/32 192.221.51.62/32 (pref=MED) accept AS3749 interas-in: from AS2637 192.221.26.2/32 192.221.26.1/32 (pref=90) accept AS2637 interas-in: from AS2637 192.76.181.1/32 192.76.181.2/32 (pref=100) accept AS2637 interas-in: from AS2048 192.221.14.17/32 192.221.14.18/32 (pref=MED) accept AS2048 interas-in: from AS2048 192.221.14.21/32 192.221.14.22/32 (pref=MED) accept AS2048 interas-in: from AS2048 192.221.5.69/32 192.221.5.70/32 (pref=MED) accept AS2048 default: AS690 100 {140.222.0.0/16} guardian: nacr@sura.net admin-c: SURA-NOC tech-c: SURA-NOC notify: nacr@sura.net mnt-by: SURA changed: sherk@sura.net 941019 source: MCI In addition to the standard whois flags supported by the whois shipped with almost every operating system, the RR whois server understands some more options that change the behavior of the out- put. There is a public domain version of the whois client developed to support all these special options. This new client will of course also work with other whois servers, but these will most probably not support the extra options. This client is available from: ftp://ftp.ripe.net/tools/ripe-whois.tar.Z MCI Confidential 11 DRAFT 5. References [1] Bates, T., Gerich, E., Jocheray, L., Jouanigot, J-M., Karren- berg, D., Terpstra, M., Yu, J., "Representation of IP Routing Policies in a Routing Registry", RIPE-181, October 1994. ftp://ftp.ripe.net/ripe/docs/ripe-181.ps [2] Bates, T., Karrenberg, D., Terpstra, M., "Support for Classless Internet Addresses in the RIPE Database", RIPE-121, October 1994. ftp://ftp.ripe.net/ripe/docs/ripe-121.ps [3] Karrenberg, D., Terpstra, M., "Authorisation and Notification of Changes in the RIPE Database", RIPE-120, October 1994. ftp://ftp.ripe.net/ripe/docs/ripe-120.ps [4] Bates, T., "The InternetMCI Routing Registry User Guide", DRAFT, November 1994. ftp://ftp.mci.net/.coren/mci-rr-user.ps [5] E. Feinler, K. Harrenstien, M. Stahl, "NICNAME/WHOIS", RFC-954, January 1985. ftp://ds.internic.net/rfc/rfc954.txt MCI Confidential 12 DRAFT Appendix A -- 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 sec- ond 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. 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 within the RR database known as the "prefix length" representation. See [2] 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 origin: The autonomous system announcing this route. Format: MCI Confidential 13 DRAFT See appendix B for syntax. Example: origin: AS1104 Status: mandatory, only one line allowed hole: Denote the parts of the address space covered this route object to which the originator does not provide connectivity. These holes may include routes that are being currently routed by another provider (e.g., a customer using that space has moved to a different service provider). They may also include space that has not yet been assigned to any customer. Format: Classless representation of a route within RR database known as the "prefix length" representation. See [2] 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. Example: withdrawn: 940711 Status: optional, one line allowed. comm-list: List of one or more communities this route is part of. Format: ... See [1] for definition. MCI Confidential 14 DRAFT 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 notifi- cations of changes to this object should be send. Format: The should be in RFC822 domain syntax wherever possible. Example: notify: Marten.Terpstra@ripe.net Status: optional, multiple lines allowed mnt-by: The mnt-by attribute contains a registered maintainer name. Format: Example: mnt-by: MCI ft P Status: optional, multiple lines allowed changed: Who changed this object last, and when was this change made. Format: YYMMDD MCI Confidential 15 DRAFT 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 InternetMCI database entries the value is fixed to MCI. Format: MCI Status: mandatory, only one line allowed MCI Confidential 16 DRAFT Appendix B -- 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 sec- ond 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. 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 allo- cated autonomous system number from an AS registry (i.e. the RIPE NCC, the Inter-NIC, etc). Format: AS Example: aut-num: AS1104 Status: mandatory, only one line allowed 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. MCI Confidential 17 DRAFT Example: as-name: NIKHEF-H Status: single, only one line allowed descr: A short description of the Autonomous System. Format: free text Example: descr: NIKHEF section H descr: Science Park Watergraafsmeer descr: Amsterdam Status: mandatory, multiple lines allowed as-in: A description of accepted routing information between AS peers. Format: from accept The keywords from and accept are optional and can be omit- ted. refers to your AS neighbor. is a positive integer used to express a relative cost of routes learned. The lower the cost the more pre- ferred the route. can take the following for- mats. 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, 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, 128.141.0.0/16} MCI Confidential 18 DRAFT 2. A set of KEYWORDS. The following KEYWORD is cur- rently defined: ANY this means anything the neighbor AS knows. 3. A logical expression of either 1 or 2 above The cur- rent 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. 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 MCI Confidential 19 DRAFT 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) 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 per- haps somewhat clearer: as-in: from AS1755 100 accept ANY AND NOT (AS1 OR AS2 OR AS3) Examples: as-in: from AS1755 100 accept ANY AND NOT (AS1234 OR AS513) as-in: from AS1755 150 accept AS1234 OR {35.0.0.0/8} A rule can be wrapped over lines providing the associated , values and from and accept keywords are repeated and occur on consecutive lines. Example: as-in: from AS1755 100 accept ANY AND NOT (AS1234 AS513) MCI Confidential 20 DRAFT 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 as-out: A description of generated routing information sent to other AS peers. Format: to announce refers to your AS neighbor. is explained in the as-in attribute definition above. Example: as-out: to AS1104 announce AS978 as-out: to AS1755 announce ANY as-out: to AS786 announce ANY AND NOT (AS978) Status: optional, multiple lines allowed interas-in: Describes incoming local preferences on an inter AS connection. Format: from accept The keywords from and accept are optional and can be omit- ted. is an autonomous system as defined in as-in. contains the IP address of the border router in the AS describing the policy. IP address must be in prefix length format. contains the IP address of neighbor AS's border router from which this AS accept routes defined in the . IP addresses must be in prefix length format. MCI Confidential 21 DRAFT is defined as follows: (=) It should be noted the parenthesis ``('' and ``)'' and the ``'' keyword must be present for this prefer- ence to be valid. currently only supports "pref". It could be expanded to other type of preference such as TOS/QOS as routing technology matures. can take one of the following values: is a positive integer used to express a rela- tive cost of routes learned. The lower the cost the more preferred the route. This value is only comparable to other interas-in attributes, not to as- in attributes. MED This indicates the AS will use the MUTLI_EXIT_DISCRIMINATOR (MED) metric, as implemented in BGP4 and IDRP, sent from its neighbor AS. NOTE: Combinations of MED and should be avoided for the same destinations. CAVEAT: The pref-type values may well be enhanced in the future as more inter-ASs routing protocols intro- duce 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 incon- sistency as an error. It should be noted that if an interas-in policy is specified then it is mandatory to specify the corresponding global policy in the as- in line. Please note there is no relevance in the cost associated with as-in and the preferences used in interas-in. is an expression as defined in as-in above. Examples: interas-in: from AS1104 192.87.45.254/32 192.87.45.80/32 (pref=10) accept AS786 AS987 interas-in: from AS1104 192.87.45.254/32 192.87.45.79/32 (pref=20) accept AS987 interas-in: from AS1103 192.87.45.254/32 192.87.45.32/32 (pref=MED) accept ANY MCI Confidential 22 DRAFT Status: optional, multiple lines allowed interas-out: Format: to [] anno unce The keywords to and announce are optional and can be omit- ted. The definitions of , , and are identical to those defined in interas-in. is optional and is defined as follows: (=) It should be noted the parenthesis ``('' and ``)'' and the keywords of ``'' must be present for this metric to be valid. currently only supports "metric-out". It could be expanded to other type of preference such as TOS/QOS as routing technology matures. can take one of the following values: is a pre-configured metric for out-bound routes. The lower the cost the more preferred the route. This value is literally passed by the routing protocol to the neighbor. It is expected that it is used there which is indicated by pref=MED on the corresponding interas-in attribute. It should be noted that whether to accept the outgoing metric or not is totally within the discretion of the neigh- bor AS. IGP This indicates that the metric reflects the ASs internal topology cost. The topology is reflected here by using MED which is derived from the AS's IGP metric. NOTE: Combinations of IGP and should be avoided for the same destinations. CAVEAT: The metric-out values may well be enhanced in the future as more interas protocols make use of met- rics. Any route specified in interas-out and not specified MCI Confidential 23 DRAFT in as-out is assumed not announced between the ASes concerned. Diagnostic tools should flag this incon- sistency 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: to AS1104 192.87.45.254/32 192.87.45.80/32 (metric-out=10) announce AS23 AS10 interas-out: to AS1104 192.87.45.254/32 192.87.45.80/32 (metric-out=15) announce AS10 interas-out: to AS1103 192.87.45.254/32 192.87.45.80/32 (metric-out=IGP) announce ANY Status: optional, multiple lines allowed as-exclude: A list of transit ASes to ignore all routes from. Format: exclude to Keywords exclude and to are optional and can again be omitted. refers to the transit AS in question. an can be ONE of the following. 1. 2. AS macro 3. Community 4. ANY Examples: as-exclude: exclude AS690 to HEPNET This means exclude any HEPNET routes which have a route via AS690. as-exclude: exclude AS1800 to AS-EUNET This means exclude any AS-EUNET routes which have a route via AS1800. as-exclude: exclude AS1755 to AS1104 This means exclude any AS1104 route which have a route via AS1755. as-exclude: exclude AS1104 to ANY MCI Confidential 24 DRAFT This means exclude all routes which have a route via AS1104. Status: optional, multiple lines allowed default: An indication of how default routing is done. Format: where is the AS peer you will default route to, and is the relative cost is a positive integer used to express a preference for default. There is no relationship to the cost used in the as-in tag. The AS peer with the lowest cost is used for default over ones with higher costs. is optional and provides information on how a default route is selected. It can take the fol- lowing 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 tech-c: Full name or uniquely assigned NIC-handle of a technical con- tact person. This is someone to be contacted for technical problems such as misconfiguration. Format: or Example: MCI Confidential 25 DRAFT tech-c: John E Doe tech-c: JED31 Status: mandatory, multiple lines allowed admin-c: Full name or uniquely assigned NIC-handle of an administrative contact person. In many cases this would be the name of the guardian. Format: or Example: admin-c: Joe T Bloggs admin-c: JTB1 Status: mandatory, multiple lines allowed guardian: Mailbox of the guardian of the Autonomous system. Format: The should be in RFC822 domain format wherever possible. Example: guardian: as1104-guardian@nikhef.nl Status: mandatory, only one line and e-mail address allowed 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 notifi- cations of changes to this object should be sent. Format: MCI Confidential 26 DRAFT The should be in RFC822 domain syntax wherever possible. Example: notify: Marten.Terpstra@ripe.net Status: optional, multiple lines allowed mnt-by: The mnt-by attribute contains a registered maintainer name. Format: Example: mnt-by: MCI Status: optional, multiple lines allowed changed: Who changed this object last, and when was this change made. Format: YYMMDD should be the address of the person who made the last change. YYMMDD denotes the date this change was made. Example: changed: johndoe@terabit-labs.nn 900401 Status: mandatory, multiple lines allowed source: Source of the information. This is used to separate information from different sources kept by the same database software. For Internet MCI entries the value is fixed to MCI. Format: MCI Status: mandatory, only one line allowed MCI Confidential 27 DRAFT 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 sec- ond 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. as-macro: [mandatory] [single] descr: [mandatory] [multiple] as-list: [mandatory] [multiple] guardian: [mandatory] [single] tech-c: [mandatory] [multiple] admin-c: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: as-macro: The name of a macro containing at least two Autonomous Systems grouped together for ease of administration. Format: AS- The should be in upper case and not contain any special characters. Example: as-macro: AS-EBONE Status: mandatory, only one line allowed descr: A short description of the Autonomous System Macro. Format: free text Example: descr: Macro for EBONE connected ASes Status: mandatory, multiple lines allowed MCI Confidential 28 DRAFT as-list: The list of ASes or other AS macros that make up this macro. It should be noted that recursive use of AS macros is to be encouraged. Format: ... See Appendix B for definition. Example: as-list: AS786 AS513 AS1104 as-list: AS99 AS-NORDUNET Status: mandatory, multiple lines allowed guardian: Mailbox of the guardian of this AS macro. Format: The should be in RFC822 domain format wherever possible. Example: guardian: as-ebone-guardian@ebone.net Status: mandatory, only one line and e-mail address allowed tech-c: Full name or uniquely assigned NIC-handle of a technical con- tact person for this macro. This is someone to be contacted for technical problems such as misconfiguration. Format: or Examples: tech-c: John E Doe tech-c: JED31 Status: mandatory, multiple lines allowed admin-c: Full name or uniquely assigned NIC-handle of an administrative contact person. In many cases this would be the name of the guardian. Format: or MCI Confidential 29 DRAFT 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 notifi- cations of changes to this object should be send. Format: The should be in RFC822 domain syntax wherever possible. Example: notify: Marten.Terpstra@ripe.net Status: optional, multiple lines allowed mnt-by: The mnt-by attribute contains a registered maintainer name. Format: Example: mnt-by: MCI Status: optional, multiple lines allowed changed: Who changed this object last, and when was this change made. Format: YYMMDD should be the address of the person who MCI Confidential 30 DRAFT 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 InternetMCI RR entries the value is fixed to MCI Format: MCIfP Status: mandatory, only one line allowed MCI Confidential 31 DRAFT Appendix D -- Syntax for the "mntner object " object. There is a summary of the tags associated with route object itself and their status. The first column specifies the attribute, the sec- ond 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. mntner: [mandatory] [single] descr: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [optional] [multiple] upd-to: [mandatory] [multiple] mnt-nfy: [optional] [multiple] auth: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: mntner: Maintainer name. Format: An upper case text string consisting of alphanumeric char- acters and "-" (dash) which is not the same as any main- tainer name already defined. The name has to be unique with regard to other maintainer names only. It can be the same as handles, autonomous system or community names. Examples: mntner: FOO-NOC mntner: NN-DOMREG Status: mandatory, only one line allowed descr: A short description of the maintainer entity. Format: free text Examples: MCI Confidential 32 DRAFT descr: FOO Networking Inc. NOC descr: Serving all customers of FOO Networking Inc. descr: Domain Registrar for the NN toplevel domain. Status: mandatory, multiple lines allowed admin-c: Full name or uniquely assigned NIC-handle of an administrative contact person. This is the one with whom coordination should be done. Format: or Example: admin-c: Joe T Bloggs admin-c: JTB1 The handle form is preferred because it is not ambiguous. The handle form is preferred because it is not ambiguous. Status: mandatory, multiple lines allowed tech-c: Full name or uniquely assigned NIC-handle of a technical con- tact person. If defined this is someone to be contacted for technical problems such as bounced e-mail etc. Format: or Examples: tech-c: John E Doe tech-c: JED31 The handle form is preferred because it is not ambiguous. Status: optional, multiple lines allowed upd-to: Updates to. Any unauthorised update request of an object main- tained by this maintainer will be forwarded to this address. Format: RFC-822 address MCI Confidential 33 DRAFT Example: upd-to: noc@foobar.net upd-to: domreg@nn-nic.nn Status: mandatory, multiple lines allowed mnt-nfy: Maintainer notification. This e-mail address will receive noti- fication messages if any object maintained by this maintainer is added, changed or deleted. The functionality is exactly the same as if a notify attribute had been defined in the object. Specifying it here has the advantage that any changes of the address(es) affect only one object. For more information see the section about the notify attribute. Format: RFC-822 address Example: mnt-nfy: noc@foobar.net mnt-nfy: domreg@nn-nic.nn Status: optional, multiple lines allowed auth: specifies which scheme will be used identify and authenticate update requests from this maintainer. Format: The scheme-ids currently defined are: NONE, MAIL-FROM and CRYPT-PW. The auth-info is additional information required by a particular scheme. When more than auth attribute is specified any of them can be used alterna- tively for authentication of updates, i.e. specifying NONE and others does not make much sense. The auth attribute is not protected information in any way; it is returned normally like any attribute by the whois server and avail- able in stored copies of the database. The strength of an authentication scheme thus has to lie in the scheme itself and cannot be based on the obscurity of the auth attribute. See the section about authentication schemes for more details. Example: MCI Confidential 34 DRAFT auth: CRYPT-PW dhjsdfhruewf auth: MAIL-FROM .*@ripe.net Status: mandatory, multiple lines allowed remarks: Remarks/comments, to be used only for clarification. Format: free text Example: remarks: This is a test/example object. Status: optional, multiple lines allowed notify: The notify attribute contains an email address to which notifi- cations of changes to this object should be send. See also the section "The Notify Attribute" near the end of this document. Format: The should be in RFC822 domain syntax wherever possible. Example: notify: Marten.Terpstra@ripe.net Status: optional, multiple lines allowed mnt-by: This attribute specifies who maintains this object in the RIPE database. See also the section "The Maintained-By Attribute". Format: Example: maintainer: FOO-NOC Status: optional, multiple lines allowed changed: Who changed this object last, and when was this change made. Format: MCI Confidential 35 DRAFT YYMMDD should be the address of the person who made the last change. YYMMDD denotes the date this change was made. Example: changed: johndoe@terabit-labs.nn 900401 Status: mandatory, multiple lines allowed source: Source of the information. This is used to separate information from different sources kept by the same database software. For Internet MCI RR entries the value is fixed to MCI. Format: MCI Status: mandatory, only one line allowed MCI Confidential 36 DRAFT