January 1994 - routing-wg - mailman.ripe.net

Draft Guarded Field document
by Tony Bates 24 Jan '94

24 Jan '94

Please find enclosed a DRAFT copy of a document describing the Guarded Field procedure. This gives details of both the process for updating guardian files as well as how conflicts are handled. The current status is that the software is in final beta test and all the auto-generated "AS" accounts/files have been generated (see doc for more details). Our plan is to turn the "guarded field" software on in the database on February 7th. There will be a short introduction for both the paper and implementation given in the routing working group session at next weeks RIPE meeting. All comments welcome. We plan to agree and close this document at the RIPE meeting. See you next week. --Tony. Support of Guarded fields within the RIPE Database * DRAFT * Tony Bates Document-ID: ripe-1nn 1. Introduction The RIPE database contains several significant attributes which make it well suited for use as part of operational procedures and confi- guration. Most significantly are the attributes which make up the RIPE Routing Registry (RR) as specified in RIPE-81 [1][2], namely the "aut-sys" and "comm-list" attributes. For these attributes to be of use to service providers they must be: o Properly authorised. o Efficient for both maintainers of the attributes and the main- tainers of the whole database. This document describes an overview of the RIPE database attributes which are guarded, the procedure for updating these guarded attri- butes and the general use of "guarded" fields within the RIPE data- base. 2. The Database Guarded Attributes All the guarded attributes currently supported in the RIPE database are contained within the "inetnum" or network object. However, the association corresponds to their relevant guarded database objects. If we look at a simple example this becomes clear: 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: AS1104 ripe-1nn.txt January 19, 1994 - 2 - 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(a)ripe.net changed: tony(a)ripe.net 940110 source: RIPE This shows that the RIPE-NCC network belongs to autonomous system 1104 and is in a community known as SURFNET. This is valuable infor- mation that could easily be used for example for routing policy pur- poses (as well as other operational uses). Currently support for the following set of guarded attributes is implemented: aut-sys The "aut-sys" attribute has a direct mapping to "aut-num" objects as defined in RIPE-81. That is the Autonomous System (AS) that the network number is a part of. As defined in RIPE- 81, a network can only belong to one AS and hence the "aut-sys" attribute can only contain one AS number. The syntax of the "aut-sys" attribute is: AS<positive integer between 1 and 65535> (1). i.e. AS1104 comm-list The "comm-list" attribute has a direct mapping to "community" objects as defined in RIPE-81. A network can belong to more than one community. The syntax of "comm-list" is: Multiple text strings which cannot start with "AS" or any of the <routing policy expression> KEYWORDS defined in RIPE-81. routpr-l (2) The "routpr-l" attribute has a direct mapping to "rout-pr" objects as defined in RIPE-60 [4]. Networks can belong to more than one routing privilege. The list of networks within a rout- ing privilege represents the group of networks accepted/allowed by a set of routers described by the information in the "rout- pr" object. The syntax for "routpr-l" is as follows: Multiple text strings representing the routing privilege. _________________________ (1) This represents a change from RIPE-50 [3] where the "aut-sys" attribute was defined to be a positive integer only, not containing the string "AS" at the start. This change has been made to be consistent with the "aut-num" object syntax. ripe-1nn.txt January 19, 1994 - 3 - bdrygw-l The "bdrygw-l" attribute has a direct mapping to "bdry-gw" objects as defined in RIPE-60 [4]. Networks can belong to more than one boundary gateway. The list of networks within a boun- dary gateway represents the group of networks advertised by a set of routers described by the information in the "bdry-gw" object. The syntax for "bdrygw-l" is as follows: Multiple text strings representing the boundary gateways iden- tification. As these attributes are tightly coupled to their associated objects it makes sense for these attributes to be updated not by the network maintainer but by the maintainer of the referenced object(s). The basic premise behind this is that these attributes should be used for various operational procedures such as setting routing policy, accounting and so on. For these attributes to be used by network operators for day to day operations they need to be guarded in such a way that can be trusted and are guaranteed to be unique - with any conflicts quickly and easily resolved. The procedure for achieving this is detailed below. 3. The Basic Procedure For each of the guarded attributes detailed above, a list of all networks having this attribute is kept separately from the general database itself. These lists (also called `guarded files') will be maintained and be served as the `only' source of membership informa- tion used in the database. Normal database updates `never' change these attributes. If an update includes such an attribute and a discrepancy between the values in the update and those in the data- base is found, a diagnostic message will be sent to the originator of the update and the guarded value(s) will not be affected. The attributes as defined in these files are incorporated in the data- base once a day. To ensure proper control and authorisation, these lists will be maintained at the RIPE NCC on the same machine that contains the RIPE database. The "guardians" of the corresponding database objects will have to maintain their own guarded files. The guardians are provided with individually assigned login accounts at the RIPE NCC. The guardians can themselves decide in what manner they want to update their file. The NCC will offer interactive logins, ftp logins or any other means that might be deemed useful. _________________________ (2) It should be noted that both "routpr-l" and "bdrygw-l" attributes have been agreed to be phased out in preference of the "aut-sys" and "comm-list" attri- butes as soon as the `guarded field' mechanism is in place. ripe-1nn.txt January 19, 1994 - 4 - 3.1. Some Details As stated each guardian will be issued with an account on the cen- tral NCC machine known as `guardian.ripe.net'. This account will contain a `restricted' environment which will allow the guardian of the relevant object to update their associated guardian file (3). Wherever possible the account name issued to the guardian will be the same as the object name. For example, the guardian of the AS1104 aut-num object will receive an account known as "AS1104". With each guardian account the corresponding file will be parsed at each update run (once a day). This file will contain the list on networks associated with the object. See appendix A for details of the format and syntax of the guardian files. A tool will also be provided within the restricted environment to syntax check the guarded file to avoid against possible typos and errors. With each account, an electronic mail address (this is a mandatory attribute for all guarded objects) will be used by the NCC and data- base software. To make this flexible for the guardian a ".forward" file with the account which can be change when required. This will mean mail sent to <guardian-name(a)guardian.ripe.net> will go the to correct guardian. 3.2. How does it work ? For each of the guarded files found on `guardian.ripe.net' the data- base software will load any guarded attribute value(s) for the net- work object(s) listed in the guarded file. This will take place at the same time as the database is garbage collected (currently at 0500 MET). If a conflict is found (i.e if more than one entry exists for an attribute which can only contain one entry, currently only "aut-sys" contains this property), the current value will remain unchanged and all guardians involved in the conflict will be sent an electronic mail message informing them of the conflict. See Appendix B for an example. If no conflict is found the attribute will be updated with the guarded value. Correspondingly, to remove a guarded attribute just remove the net- work entry from the relevant guarded file and it will be deleted at the next update run. To be notified of this delete the "notify" attribute should be used. _________________________ (3) As stated, the mechanism for updating the guardi- an file will initially be by interactive login or file transfer. However, this doesn't preclude other mechan- isms in the future. ripe-1nn.txt January 19, 1994 - 5 - If a guardian file contains an entry which is not in the database then the guardian will be notified as part of the conflict handling procedure. If an update is sent to the database software using another mechan- ism (i.e. mail to auto-dbm(a)ripe.net) that contains a guarded attri- bute, this will not be allowed to change the guarded attribute. If the value of the attribute is the same as what is currently registered in the database then no warnings will be given. However, if the update contains a value for a guarded attribute that is dif- ferent to that registered in the database, a warning will be sent to the originator and the guarded value will remain unchanged. Although the guarded process will run once a day as part of the database garbage collection procedure it will also be possible to, "on request to the NCC", run an emergency guarded update process for a particular guarded object. 4. Getting it started As this is a new (and much needed, especially for the "aut-sys" attribute) mechanism, a degree of `bootstrapping' is needed to make it easier for network providers and IRs to transition to using the guarded file procedure. The NCC has built an automated generation scheme for attributes that are known to be in use (currently, this means AS numbers). For all the AS numbers seen to be routed in Europe, accounts for the guardians have already been put in place having the guardian's mailbox point to a mailbox at the RIPE NCC. For these ASs currently guarded files are generated on a daily basis by analyzing European full routing tables. This means there could (and almost certainly will) be some conflicts within the generated guardian files. As soon as the account is handed over, the auto-generation for that guardian account stops and the mailbox is changed to the correct guardian mailbox. Guardians can of course make use of the auto- generated guarded files if they wish to check against their own records. From the moment of `hand-over' it is now the guardians responsibility to make sure their associated network(s) get the correct guarded attributes by listing them in the guarded files. The advantage of having this `bootstrap' method is that it will allow population of the guarded "aut-sys" attribute to take place immediately this functionality is enabled in the RIPE database software. It also acts as an incentive for networks operators and local IR's to transition to the guarded file procedure as soon as possible. 5. Conclusion The update procedure as detailed above has the following advantages: o Authorisation of adding/deleting is guaranteed. ripe-1nn.txt January 19, 1994 - 6 - o No need for mailing back and forth of authorisation messages. o Simple procedure for both database maintainers and guardians. o Guardians keep full control of their attribute. It allows for the addition of any number of guarded attributes in the future. It describes a simple but effective procedure for main- taining the guarded files whilst not precluding alternate mechanisms in the future. 6. 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] Bates, T., Karrenberg, D., "Description of Inter-AS Networks in the RIPE Routing Registry", RIPE-103, December 1993. [3] Karrenberg, D., "RIPE Database Template for Networks", RIPE-50, April 1992. [4] J.-M. Jouanigot, "Policy based routing within RIPE", May 1992. ripe-1nn.txt January 19, 1994 - 7 - Appendix A - Format of Guardian Files. We propose to keep the file format as simple as possible. The name of the file is identical to the name of guarded object. The format used within the file is kept simple. It allows lines to be either comments or the actual object entry that is to be guarded. A comment must contain either a semi-colon (;) or hash (#) at the beginning of the comment line. The object name entries must be exactly the same as they are in the database. Currently, the only object containing guarded attributes is the "inetnum" object so the file can contain either the `well-known' dotted quad network notation or RIPE dotted quad range notation. Here is a simple example of what the AS1104 guarded file would look like. The file would be stored in the home directory of the AS1104 account on guardian.ripe.net and be called AS1104 (told you it was simple). It would contain something like the following: # # File : AS1104 # ; An alternate comment format ; ; This file was updated jan.dijkstra(a)gouda.nl ; on 940109 ; 192.16.183.0 192.16.185.0 - 192.16.186.0 192.16.194.0 192.16.199.0 192.87.45.0 Empty lines in the file are also ignored but you are encouraged to keep the file as concise as possible. As stated above, a tool known as `checkguard' will be available to make it simple to check the syntax of the guarded file. ripe-1nn.txt January 19, 1994 - 8 - Appendix B - Example of conflict handling If a conflict occurs (e.g. by listing the same network number in more han one AS guarded file), then each of the guardians involved will be notified on the conflict by electronic mail. Let's look at a simple example. Suppose the guardians for AS1104 and AS2122 update their relevant guardian files and create a conflict by having the same network in them. For this example he network in question is "192.16.183.0". Here is the AS1104 guardian file: # 192.16.183.0 192.16.185.0 192.16.186.0 192.16.194.0 192.16.199.0 192.87.45.0 And here is the AS2122 guardian file: # 192.16.183.0 193.0.0.0 - 193.0.7.0 As you can see "192.16.183.0 exists in both files. At update time the following mails are generated. Firstly, to the guardian of AS2122. Date: Fri, 14 Jan 1994 13:22:43 +0100 Message-Id: <9401141222.AA07125(a)ns.ripe.net> From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net> Subject: Guarded attributes conflicts found To: as2122(a)ripe.net Dear Guardian, One or more conflicts have been found regarding guarded attributes in the RIPE database. Some of the conflicts concern the guarded values you are a guardian for. Please verify and correct the conflicts below. The guarded values for objects below have been set to the value they had in the database before this guarded attributes run. Kind Regards, RIPE Database Conflict Department ------ "192.16.183.0" also appears in guardian files: AS1104 And similarly to the AS1104 guardian. ripe-1nn.txt January 19, 1994 - 9 - Date: Fri, 14 Jan 1994 13:22:42 +0100 Message-Id: <9401141222.AA07121(a)ns.ripe.net> From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net> Subject: Guarded attributes conflicts found To: as1104(a)ripe.net Dear Guardian, One or more conflicts have been found regarding guarded attributes in the RIPE database. Some of the conflicts concern the guarded values you are a guardian for. Please verify and correct the conflicts below. The guarded values for objects below have been set to the value they had in the database before this guarded attributes run. Kind Regards, RIPE Database Conflict Department ------ "192.16.183.0" also appears in guardian files: AS2122 >From this you can see conflict can be quickly and easily resolved, assuming good collaboration between the guardians. The existing database entry will of course not be changed with regard to the guarded attribute) as long as there exists a conflict. ripe-1nn.txt January 19, 1994

3 4

Draft on CIDR FAQ
by vannozzi＠nis.garr.it 21 Jan '94

21 Jan '94

Hello all, you can find below the draft on CIDR FAQ produced by Giuliana Tamorri. All comments and suggestions welcome. Daniele ---------------------------------------------------- GARR-NIS January 1994 FAQ on CIDR DRAFT DRAFT DRAFT DRAFT 1) What is CIDR? Classless Inter-Domain Routing (CIDR) is an architecture for allocating IP addresses in the Internet [1]. It plays an important role in steering the Internet towards the Address Assignment and Aggregating Strategy [3]. 2) Why do we need to plan an architecture such as CIDR? The IP address space is a scarce shared resource that must be managed for the good of the community. Due to the growth of the Internet, some scaling problems arosen [2,3,6,11]: - Exhaustion of the class-B network address space. More than half of the total class B address space has been handed out. One fundamental cause of this problem is the lack of an appropriate sized network number for a mid-sized organization. Class-C, with a maximum of 254 host addresses, is too small, while class-B, which allows up to 65534 addresses, is too large to be densely populated. The result is inefficient utilization of class-B network numbers. - Routing information overload. The size and rate of growth of the routing tables in Internet routers is beyond the ability of current software (and people) to be effectively managed. This is mainly a problem for those routers which don't use a default route, and have to carry a routing entry for each network they need connectivity to. The current growth trend is approximatelly exponential. - Eventual exhaustion of IP network numbers. With more than half of the class B networks assigned and a little over 6 percent of the class C networks assigned, and the current growth in the address allocation rate, this is a real, though not imminent danger. The first two problems will become extrimely critical in a near future. CIDR defines a mechanism to: i) slow the growth of routing table providing a mechanism for aggregation of routing information ii) reduce the need to allocate new IP network numbers managing the allocation of Internet address space. [page 1] The last point takes great advantages from the assigment policy reported in RFC 1466 [10] in which a managing schema for IP Address Space is defined. The rules of the class C network number allocation defined in [10], will quickly accelerate the explosion of the routing information carried by Internet routers. Anyhow, assignment of consecutive class C network number will facilitate and favourite the aggregation mechanism developed by CIDR. The rule foresees to delegate to the network service providers the address allocation of the class C network numbers. 3) Is CIDR a solution to the serious scaling problem of the Internet? Yes, it is, but not a permanent one. It is a transition phase, or a short-term solution, in order to allow the development of a long-term solution, which will also cover the problem of the exhaustion of IP network numbers. CIDR will mainly deal with the solution (since the present problem, a short-term one) of the routing table explosion problem. 4) Which are the aspects analyzed in realising an Address Allocation schema? Some of the technical and administrative aspects of an IP address allocation faced in deploying a CIDR architecture are reported in [1]: - Benefits of encoding some topological information in IP addresses to significantly reduce routing protocol overhead; - The anticipated need for additional levels of hierarchy in Internet addressing to support network growth; - The recommended mapping between Internet topological entities (i.e., service providers, and service subscribers) and IP addressing and routing components; - The recommended division of IP address assignment among service providers (e.g., backbones, regionals), and service subscribers (e.g., sites); - Allocation of the IP addresses by the Internet Registry; - Choice of the high-order portion of the IP addresses in leaf routing domains that are connected to more than one service provider (e.g., backbone or a regional network). - Identification of specific administrative domains in the Internet. [page 2] 5) Which is the Authority to which an organization could ask for a network number? The centralised procedures for obtaining IP network numbers from the Global Internet Registry (known as InterNIC previously the DDN NIC) is now replaced by a distributed allocation schema [10,12,13]. At the present, there are a number of Distributed Regional Registries to which Internet Registry (IR) and the Internet Assigned Numbers Authority (IANA) have delegated the registration function on a geographic area. These Regional Registres cover many geographical areas; but until an organization is identified in those regions, the IR will continue to serve as the default registry. That is, the IR remains the root registry and continues to provide the registration function to all those regions not covered by distributed regional registries. So, it is possible for network applicants to contact the IR directly, but it will be referred to the Regional Registry, if any. Regional Registry in turn delegates blocks of IP network numbers to local IR's. They are of two types: "service provider" and "registry of last resort". An IP service provider is an organisation that supplies Internet connectivity to its customers or users (examples are academic network providers and commercial network providers). "Registry of last resort" local IR's are managed by organisations that are prepared to handle requests from organisations that have no present or planned connection to the Internet. The diagram below shows the distributed hierarchy of IR. Global IR (InterNIC) | | Regional IR (RIPE NCC) | ________________________|____________________ | | | | Local IR Local IR Local IR Local IR / / ( "REGISTRY" (SERVICE PROVIDERS) (SERVICE PROVIDER) OF LAST RESORT") In Europe, the IR has now delegated blocks of IP network numbers to the RIPE NCC as the registry for the European region, which following the main criteria, delegates blocks of IP network numbers to local IR's. If you are NOT a customer of a service provider, then you should send your completed application form to the "registry of last resort" local IR. Currently only one of this type of registry exists in the european countries. 6) Which are the criteria to submit an appropriate request for a block of class C network number? It mainly depends on the organizational network topology, ie number of internal LANs, and on the needed address numbers, taking in mind [page 3] the end system type, ie hosts, routers, printers, terminal server, etc. The following schema, which takes in consideration the number of hosts to be connected per network, could be a starting guide to evaluate the number of class C networks to be applied for. 1 class C ----> 254 hosts 2 class C ----> 508 hosts 4 class C ----> 1016 hosts 8 class C ----> 2032 hosts 16 class C ----> 4064 hosts 32 class C ----> 8128 hosts Moreover, if the network is divided into logically distinct LANs across which it could be difficult to use a smaller number of class C network numbers, the above criteria may apply on a per-LAN basis. It is important to submit the request with an engineering plan which can motivate it. If the request will be inappropriate, it will be investigated and suggested a different solution which could take advantage of the feasibility of subnetting Class C network numbers which can resolve the need of a great number of Class C network; in particular, it can resolve the problem of requesting a network number for every subnet. If there is a need for more than 4096 unique IP addresses it could conceivably receive a Class B network number. The maximal block of Class C network numbers that should be assigned to a subscriber consists of 64 contiguous Class C networks. This would correspond to a single IP prefix of 18 bits. It is also important that an organization could foresee its growth in requesting the block of contiguos network numbers. As a consequence, submitting its forms to its Local Registry, an organization must indicate which could be its immediate growth in terms of number of machines to be connected and of subnet numbers foreseen for its network. 7) When could an organization consider to approach a subnetting criteria? If an address space needed for an organizatin covers only about tens addresses, and there are no plans to expand in the future, it makes little sense to allocate a full class C network number for this local network [11]. More details on subnetting technique can be found in [14], a Standard Internet. However, two issues must be taken into consideration in subnetting class C networks: i) subnets and hosts numbered "0" and "-1" are reserved for special purpose in IP (broadcast and this host/subnet indication. [page 4] ii) which kind of protocol to be used to distribute subnets information within the network. Limits imposed by the first point have led to the development of some technique which can improve the address space utilization. One of them is "variable-lengh subnet mask" (VLSM). For the second issue, it is suggested to use a new generation interior protocol. With old ones, such as RIP, it is quite impossible to distribute information on subnets. While with the new ones, as OSPS, integrated IS-IS or RIP-2, announced destinations carry a corrisponding network mask, favouring the subnetting mechanism. 8) Which would be an appropriate request for a class B network number, in order to be approved? An organization applying for a class B network number must present a subnetting plan which documents more than 32 subnets within its network and must have more than 4096 hosts. The submitted document must demonstrate the impossibility of engineering the network with a block of class C network numbers. The engineering plan must include both how many hosts and how many hosts per subnet the network will have within the next 24 months. 9) What does hierarchy mean in Internet addressing? How could hierarchy help in reducing the growth of routing table? The situation in which each domain may have non-contiguous network numbers assigned to it could lead to a dissemination of routing information in the Internet. If routing domains are randomly interconnected, it is difficult to obtain a degree of routing data abstraction. Moreover, at a lower level, if IP addresses within a routing domain are all drawn from non-contiguous IP address spaces (allowing no aggregation or abstraction), then the information exchanged between boundary router consists of an enumerated list of all the IP addresses. Anyhow, being service providers and service subscribers (ie sites, routing domain) arranged hierarchically in the Internet, it is natural to map this hierarchy also to the IP routing components. The aim of using a hierarchical routing is to achieve some level of routing data abstraction: an element lower in the hierarchy reports summary routing information to its parents. The idea is to assign to any group of routing domains an address prefix from a a shorter prefix given to a routing domain which has the function of interconnecting the group of routing domains. It is clear that the routing abstraction carries more advantages at a higher levels of the hierarchy. 10) Does it mean all the routing domains in the Internet need to convert to CIDR? No, it is not required all Internet domains to be converted to use CIDR, neither now nor in the future; anyhow, it is assured [page 5] the global connectivity, including for those non-CIDR domains for which, however, optimality of routes could be impacted. The only constrain on a non-CIDR-capable domain is the need to default towards the CIDR-capable parts of the Internet for routes which have been aggregated to non-network boundaries [2]. Anyhow, it is strongly reccommended that all non-backbone/transit Internet domains also implement CIDR because it will reduce the amount of routing information inside them. Any connected domain that supports IP version 4, could implement CIDR. On the contrary, it is imposed ALL Internet domains providing backbone and/or transit service to fully implement CIDR, ensuring a slow growth of the routing table, while providing Internet-wide connectivity. 11) Which are the protocols supporting CIDR architecture? Two main protocols realising the CIDR architecture are: i) Border Gateway Protocol 4 (BGP-4) ii) Inter-Domain Routing Protocol (IDRP for IP) Each of them are inter-domain routing protocol, but the last one has been standardized within ISO as multi-protocol. BGP-4 is an extension of BGP-3 that provides support for routing information aggregation and reduction based on CIDR architecture. They are quite interchangeble [6]. 12) What is an aggregate? What is an IP-prefix? What an IP-mask? CIDR removes the concept of class A, B and C networks providing a new representation of the destination address as a combination of an address and a mask. The aim is to represent multiple contiguos class C networks with a single routing table entry [11]. CIDR requires that inter-domain routing protocols be capable of handling reachability information that is expressed solely in terms of IP address prefixes [2]. It is possible to support aggregation through the use of an IP address prefix. Indipendently of the "class" of IP network number, an aggregate collects a set of network addresses matching a pattern. In other words, an aggregate combines announcements for a set of separate networks into a single net aggregate. It is now visible how the notion of "class" in routing information will lose importance. It is not mandated the use of a particular IP address prefix, and till now there is no standardized one. [page 6] In [1], an IP-prefix is a tuple: <IP-address IP-mask> such that a bitwise logical AND operation on the IP-address and IP-mask components of a tuple yields the sequence of leftmost contiguous significant bits that form the IP address prefix. For example a tuple with the value <193.1.0.0 255.255.0.0> denotes an IP address prefix with 16 leftmost contiguous significant bits. In [7], which describes the NSFNET aggregation schema, an aggregate is described as: <net-IP prefix-length>. This refers to the IP prefix "net-IP", with a mask which has "prefix-length" 1's as counted from the high-order end. For example, <192.64.128 17> is equivalent to <192.64.128, 255.255.128.0> [7]. They choose to use a prefix-length rather than the mask, considering it more compact. 13) What is a CIDR Aggregate Registry? It has become evident the need for sharing of aggregate information; there is a clear need to have a separate database which will allow aggregate information from any Autonomous System to be stored and made available for easy electronic retrieval. This information can be used for routing coordination and policy configuration in the larger inter-domain context. One of the expected uses of such a database is to help determine, as CIDR matures, the granularity of aggregation of network reachability information with respect to policy. In [7], Merit proposes an implementation of an "Aggregate Registry" to provide sharing of aggregate information for the Internet inter-domain routing community. It should be a community registry and MERIT invites all to use and make use of it. It will consist of a list of aggregate announcement statements. 14) Who does realise aggregation? Speaking in term of BGP, a border BGP router of an AS will be responsable for generating the aggregated route for a whole set of destination IP addresses (NLRI) under its administrative control. NLRI [6] stays for Network Layer Reachability Information and represents a set of destination IP addresses over which a border BGP speaker has an administrative control. When aggregating NLRI, a border BGP must be cognizant of the implication on routing policies [6]. [page 7] References: [1] Y. Rekhter, T. Li, "An Architecture for IP Address Allocation with CIDR" RFC 1518, T.J. Watson Research Center, IBM Corp., cisco Systems, September 1993. [2] R. Hinden, "Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)", RFC 1517, Internet Engineering Steering Group, September 1993. [3] V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRNet, cisco, Merit, and OARnet, September 1993. [4] Y. Rekhter, C. Topolcic, "Exchanging Routing Information Across Provider Boundaries in the CIDR Environment", RFC 1520, T.J. Watson Research Center, IBM Corp., CNRI, September 1993. [5] C. Topolcic, "Status of CIDR Deployment in the Internet", RFC 1467, CNRI, August 1993. [6] Y. Rekhter, S. Hares, "Application of the Border Gateway Protocol and IDRP for IP in the Internet", <draft-ietf-bgp-idrp-usage-00.txt>. [7] M. Knopper, S. J. Richardson, "Aggregation Support in NSFNET Policy-Based Routing Database", RFC1482, Merit/NSFNET, June 1993. [8] C. Huitema, "IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling", RFC 1481, Internet Architecture Board, July 1993. [9] C. Topolcic, "Schedule for IP Address Space Management Guidelines", RFC 1367, CNRI, October 1992. [10] E. Gerich, "Guidelines for Management of IP Address Space", RFC 1466, Merit, May 1993. [11] H. Eidnes, "Pratical Consideration for Network Addressing using CIDR Block Allocation", Network Address Assignment, Proc.INET '93. [12] "European IP network number application form & supporting notes", ripe-107. [13] D. Karrenberg, M. Terpstra, "European Internet Registry: IP Address Space Assignment Procedures", ripe-104. [14] J. Mogul, J. Postel, "Internet standard subnetting procedure", RFC 950, Stanford, ISI, Agust 1985. [page 8] -- Daniele Vannozzi Phone: +39 50 593280 GARR - Network Information Service Fax: +39 50 904052 Via Santa Maria 36 Telex: 500371 - CNUCE 56126 Pisa - Italy E-mail: vannozzi(a)nis.garr.it ----- -----

1 0

Proposal for a CLNS routing domain object for the RIPE database.
by Henk Steenman 21 Jan '94

21 Jan '94

Here is the proposal for the CLNS routing domain object for the RIPE datase as will be presented next tuesday during the DB workgroup meeting. This version is almost similar as the one presented at a previous RIPE meeting. The main differences are a new attribute "dom-name", an introduction describing shortly why such an object is desired and an appendix that gives a very short comment on the breakdown of NSAP's for some commonly used AFI's. - Henk Steenman SARA, NIC - --------------------- CUT HERE --------------------------------------------- CLNS routing-domain object for the RIPE database Version 1.2 Jan 1994 Henk Steenman Henk_Steenman(a)sara.nl +31 20 5928038 CLNS routing-domain object Page 2 Introduction. ____________ In the RARE lower layer technology work group for CLNS it was recognised that in order to coordinate routing between CLNS routing domains a central registry for such domains was necessary. At a meeting of the work group at the 27 IETF in Amsterdam it was decided to write a registry specification. At this meeting the RIPE NCC offered to extend their database for IP domains/networks with CLNS related objects if a sound proposal came forward. Below a description of a database object for CLNS routing domains is defined. The object can be used to describe some general information of a CLNS routing domain such as NSAP prefix, name, description and responsible persons. It can also be used to describe routing policies in a manner comparable to that for IP domains ( AS's ) as defined in the paper RIPE 81 [1]. The attributes describing routing policy are intended to be set-up such that routing tables for static inter-domain routing can be derived from them or excisting routing can be checked against the described policy. It is desired that tools are made to serve these tasks. It is understood that the object as described below is subject to change when CLNS routing developes. An example of this could be the future availability of IDRP for dynamic inter-domain routing. In an appendix, some generally used combinations of the Authority and Format Identifier (AFI) and the Initial Domain Identifier (IDI) are shown. CLNS routing-domain object Page 3 Object Description _________________ dom-prefix: Defines an unique routing domain, characterised by a NSAP prefix , within a certain prefix hierarchy. Example: dom-prefix: 39528f1100 dom-name: String representing the routing domain. Format: Text string. Example: dom-name: SURFnet-CLNS descr: Description of the organisation and place of its location Format is equal to the descr attribute as defined for IP autonomous systems in [1]. bis: Format : < bis NET > < dom-prefix > NET of boundary intermediate system to between two domains Example: SURFnet BIS for EuropaNet bis: 39528f1100100020000000000100000c0429b400 39528f1103 CLNS routing-domain object Page 4 dom-in: Description of accepted routing domain prefixes, from other domain BIS. Analogue to "as-in" in [1]. Format:< dom-prefix > < cost> <routing policy expression > For every BIS you peer with, there should be such an entry <dom-prefix> is the routing domain prefix where the BIS you peer with belongs to. <cost> is a relative cost to discriminate between different routes to the same domain. The lowest cost gives the most preferred route. <routing policy expression > can be expressed in the following way's 1: list of "dom-prefixes" Example: dom-in: 39528f1103 100 39124F 470005 2: KEYWORD Only one keyword for the moment ANY - accept everything you get announced. 3: A logical expression of 1 and/or 2. The following operators should be defined AND OR NOT Parenthesis are used to group rules. Example: dom-in: 39528f1103 ANY AND NOT 39756f Accept all announcements from EMPB BIS except for the Switzerland routing domain. CLNS routing-domain object Page 5 dom-out: Routing domain prefixes announced to other BIS'. Analogue to the "as-out' tag in [1]. Format : < dom-prefix > <routing policy expression > <dom-prefix> is the routing domain prefix where the BIS you peer with belongs to. <routing policy expression > As defined with the dom-in tag. Example: dom-out: 39528f1103 39528f1100 AND NOT 39528f1100000910 Advertise to Europanet the SURFnet-CLNS routing domain but not the PTT-Research routing domain. default: Indication how default routing is done default: < dom-prefix> <cost> <dom-prefix> again is the prefix of the domain where the BIS peer is in. <cost> indicates which default path is preferred. In a static routing environment this doesn't make sense. Example: default: 39528f1103 10 Default everything is routed to 39528f1103 CLNS routing-domain object Page 6 admin-c: Administrative contact. Format equal to admin-c in [1]. tech-c: Technical contact Format equal to tech-c in [1]. guardian: e-mail and/or postal address of domain guardian. Analogue to AS guardian in [1]. source: Source of the information. Equal to source field in [1]. remark: remarks or comments Equal to remark field in [1] changed: Who and when of last change. Equal to change field in [1]. CLNS routing-domain object Page 7 Example: _________ dom-prefix: 39528f1100 descr: SURFnet-CLNS domain. bis: 39528f1100100020000000000100000c0429b400 39528f1103 dom-in: 39528f1103 100 ANY AND NOT 39528f1100000910 dom-in: 39528f1100000910 100 39528f1100000910 dom-out: 39528f1103 39528f1100 AND NOT 39528f1100000910 dom-out: 39528f1100000910 39528f1100 default: 39528f1103 10 admin-c: Victor Reijs tech-c: Henk Steenman guardian: domain-guardian(a)surfnet.nl source: RIPE changed: henk(a)sara.nl 930716 SURFnet accepts from EMPB ( 39528f1103 ) all prefixes but one, 39528f1100000910, which is PTT-research that is connected to both EMPB and SURFnet. From PTT-research SURFnet only accepts the PTT-research prefix. SURFnet announces to EMPB, 39528f1100 but not 39528f1100000910. To PTT-research only 39528f1100 is announced. Translated to static routing; on the SURFnet BIS connected to PTT- research, there is a static route to 39528f1100000910. And on the SURFnet BIS connected to EMPB there is a static route to all other know prefixes. On both the PTT-reserach and EMPB BIS's connected to SURFnet there is a static route to 39528f1100. CLNS routing-domain object Page 8 Appendix A. ___________ Definition of NSAP structure is defined in OSI 8348 Ad2 [2]. In general: NSAP's are always an integer number of octets where the AFI is always one octet and the IDI is always an integer number of octets. NSAP's are hierarchical structured and once the AFI is decided upon, structuring of the rest of the NSAP is up to authorities down the tree. Two common AFI are 47 and 39 and can be described by some general rules. AFI: 39 Describes that the following two octets are the ISO DCC country codes. Since these codes are always described by three digits, padding with an "f" is necessary to complete the 2 octets. Further structure is done by the authority for each country and there is no general rule. AFI: 47 IDI: 4 defines OSINET. Followed by a two byte organisation identifier. IDI: 5 defines US-GOSIP Version 1 defines a two byte organisation identifier. Version 2 defines a one byte data format identifier, a two byte zero field a three byte administrative authority a two byte routing domain id. ^L ^L CLNS routing-domain object Page 9 References __________ [1] : RIPE-81, Representation of IP routing Policies in the RIPE database, Tony Bates, Jean-Michel Jouanigot, Daniel Karrenberg, Peter Lothberg and Marten Terpstra, Feb. 1993 [2] : Network Services Definition, Addendum 2, covering Network Layer Addressing.

1 0

WG agenda
by jimi＠dxcoms.cern.ch 21 Jan '94

21 Jan '94

Here is the agenda of the coming Routing-WG. Blasco, I put you on the agenda just to introduce the subject (you remember de discussion on the list), but I will present the issues myself (I'll have some slides about it). If you want any other item to be discussed, please let me know. See you all in Amsterdam, -- Jean-Michel ------------------------------- RIPE Routing-WG Draft Agenda Amsterdam, Tuesday January 25th 0. Previous minutes; action list (5 minutes) Minutes taker 1. Ripe-81 1.1 Introduction; AS registration statistics (NCC) 1.2 Guarded attributes (NCC) 1.2.1 Implementation (discussion, hopefully agreement) 1.2.2 Block splitting (Marten), discussion 1.3 Use of Ripe-81; conversion of Ripe-60 (reminder, brief) 1.4 Ripe-81 enhancements 1.4.1 DMZ (Description of Inter-AS Networks in the RIPE Routing Registry" (ptraceroute issue). Status (brief) 1.4.2 Colouring, proposal, discussion 1.5 Ripe-81 limitations and pending issues 1.5.1 AS macros (Ripe-81 proposal), examples, discussion 1.5.2 Default route representation (Blasco), what can't we represent ? 1.5.3 Inter-AS Local Information, discussion 2. Closing, AOB ------------------------------

2 1

needed hints on FAQ
by giuliana＠nis.garr.it 04 Jan '94

04 Jan '94

Hello all, having proposed myself as volunteer in documenting the FAQ on CIDR and subnetting, I have tried to collect a list of documents on which basing in writing the FAQ. I would like to have any suggestion from you regarding which documents, included into the following list or not, would be better to focus the arguments. Moreover, I would appreciate any hint about which queries are commonly asked. Many tanks in advance Giuliana Tamorri =============================================================================== 001: [1000] ripe-m-14 1731 002: [1000] rfc1520 507 003: [1000] draft-ietf-iesg-cidr-01 82 004: [ 870] draft-fuller-cidr-strategy-03 56 005: [ 826] draft-egevang-addrtrans-01 619 006: [ 783] draft-rekhter-cidr-environment-01 58 007: [ 609] draft-ietf-bgp-idrp-usage-00 1294 008: [ 609] draft-ietf-sip-ipae-transition-00 3468 009: [ 609] draft-ietf-sip-overview-00 1237 010: [ 583] ripe-073 1719 011: [ 565] draft-ietf-osinsap-allocation-00 2441 012: [ 542] ripe-m-12 1452 013: [ 542] ripe-m-15 1481 014: [ 542] ripe-048 403 015: [ 539] rfc1482 619 016: [ 522] draft-hares-idrp-05 1191 017: [ 522] draft-ietf-bgp-application-03 1179 018: [ 500] ripe-m-16 1709 019: [ 478] 1id-abstracts 2574 020: [ 478] draft-iab-ipversion7-00 914 021: [ 478] draft-ietf-bgp-bgp4-implement-00 282 022: [ 478] draft-nsfnet-aggregation-00 60 023: [ 458] ripe-104 308 024: [ 435] draft-ietf-ripv2-protocol-analysis-00 222 025: [ 410] rfc1519 1347 026: [ 348] draft-ietf-osids-ipinfo-x500-dir-00.ps /local/spool/ftpp 2467 027: [ 348] draft-ietf-osids-ipinfo-x500-dir-00 1254 028: [ 333] rfc1517 227 029: [ 316] rfc1467 507 030: [ 304] draft-hitchcock-eid-00 292 031: [ 291] ripe-100 1957 032: [ 290] rfc1380 1235 033: [ 273] rfc1518 1515 034: [ 250] ripe-062 1451 035: [ 250] ripe-087 1764 036: [ 217] 1id-index 858 037: [ 217] draft-houldsworth-sc6-documents-00 315 038: [ 217] draft-ietf-bgp-bgp4-06 3191 039: [ 217] draft-ietf-ipidrp-sip-01 1180 040: [ 217] draft-ietf-ospf-mib-01 5428 041: [ 217] draft-rekhter-ipaddress-guide-08 56 042: [ 208] ripe-a-14 141 043: [ 208] ripe-079 1390 044: [ 208] ripe-083 1040 045: [ 208] ripe-085 174 046: [ 208] ripe-088 979 047: [ 208] ripe-090 1578 048: [ 208] ripe-095 979 049: [ 208] ripe-098 979 050: [ 171] rfc1540 1907 051: [ 162] rfc1481 115 054: [ 85] rfc1347 561 055: [ 85] rfc1387 171 056: [ 85] rfc1539 1235 058: [ 59] rfc1454 843 059: [ 51] rfc1383 787 060: [ 42] rfc1335 395 061: [ 42] rfc1371 507 062: [ 42] rfc1466 563 063: [ 42] rfc1475 1963 -- ---------- ------------- Giuliana Tamorri E-mail: giuliana(a)jolly.nis.garr.it GARR-NIS Phone NIS: +39 50 593360 c/o CNUCE - Istituto del CNR Fax: +39 50 904052 via S. Maria, 36 Telex: 500371 - CNUCE 56126 PISA Italy ---------- -------------

1 0