____________________________________________________ RIPE NCC Database Documentation A. M. R. Magee RIPE NCC Document: ripe-157 Date: 29 May, 1997. Obsoletes: ripe-153 Supplemented by: ripe-189 ABSTRACT This document is an introduction to the use of the RIPE Network Management Database (the "RIPE Database"). It con- tains details of how to query the database and how to create, change and delete information. It also contains instructions on authoriz- ing and authenticating changes to database objects. Items marked with an "*" character are still in production. Questions and comments about this document should be sent to . ____________________________________________________ ripe-157.txt Page 1 ripe-157 A. M. R. Magee ____________________________________________________ Acknowledgements The author wishes to acknowledge the cooperation given by the following staff at the RIPE NCC: D. Karrenberg, C. Orange, M. Kuhne, P. Caslav, C. Fletcher, E. McGuinness, R. Wilhelm and E. Willems. The author acknowledges the very helpful comments of M. Norris, HEA. Copyright Declaration on the RIPE Database "Copyright (c)1992/1993/1994/1995/1996/1997/1998/1999 by RIPE NCC Restricted rights. Except for agreed Internet operational purposes, no part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, without prior permission of the RIPE NCC on behalf of the copyright holders. Any use of this material to target advertising or similar activities are explicitly forbidden and will be prosecuted. The RIPE NCC requests to be notified of any such activities or suspicions thereof". It should be stressed that this copyright is asserted to prevent the abuse and undue exploitation of the RIPE Network Management Database. Outline of this document Software Requirements 1. Background to the RIPE Network Management Database; * Description of the objects in the database * Management of the objects 2. Using the Database ____________________________________________________ ripe-157.txt Page 2 ripe-157 A. M. R. Magee ____________________________________________________ * Querying the database * Creating, Updating and Deleting Objects * Authorization and authentication of changes * Hierarchical object protection: Inetnum objects; Domain objects* * Mirroring 3. Use of the software to run a private database* Appendix * Attributes * Objects * TEST Database* * Glossary* * Mailing Lists * A brief history of RIPE, the NCC and the Database.* Software Requirements To access the RIPE Network Management Database, you will need one of several TCP/IP based tools, namely : * `whois' client, RIPE `whois' client * WWW, http://www.ripe.net/db/ * WAIS * Telnet * E-mail The database software uses a `whois' (RFC954) server with some special RIPE specific extensions. There- fore, a 'whois' client is generally the preferred tool for database look-ups, in particular, the RIPE version. The source code of the RIPE 'whois' client ____________________________________________________ ripe-157.txt Page 3 ripe-157 A. M. R. Magee ____________________________________________________ program, which runs on UNIX, can be obtained from : ftp://ftp.ripe.net/tools/ripe-whois-tools-VER- SION.tar.gz Changes to the RIPE Database can only be made by e- mail. They can not be made using the web-site. The RIPE database has its own interface software. A public version of this software is available at ftp://ftp.ripe.net/ripe/dbase/software This software may be used by anyone to either set up a mirror of the RIPE database or to make a private database. This software is covered by the copyright below: Copyright (c) 1999 RIPE NCC All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of the author not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS; IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSE- QUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ____________________________________________________ ripe-157.txt Page 4 ripe-157 A. M. R. Magee ____________________________________________________ 1.1 The RIPE Network Management Database Purpose of the RIPE Database: One of the activities of RIPE is to maintain a database of European IP networks, DNS domains, their contact persons and IP routing policies (i.e. the RIPE Routing Registry). This data is maintained by RIPE NCC along with various other kinds of net- work management information. This database is known as the RIPE Network Management Database or more usually, the "RIPE Database". The information in the database is available to the public for agreed Internet operational purposes. This supports NIC's/NOC's all over Europe and beyond to perform their respective tasks. For example, if a user in network A cannot reach a machine in network B, then the network manager of network A could find out the technical contact per- son of network B and ask them to locate and solve the problem. The RIPE database is not a "telephone directory" or "white pages" service for European Internet users. 1.2 Description and Management of the Database Objects The RIPE Network Management Database (often called the "RIPE Database") contains records of o allocations and assignments of IP address space (the IP address registry); o domain names (the domain registry); o routing policy information (the routing reg- istry); o contact information (details of people who are responsible for the operation of networks or routers, and those who are responsible for maintaining information in the RIPE Database). Note: the information in the domain registry has no effect on operations; it is there as a convenient reference. It is not the domain registry as main- tained by the TLD's. ____________________________________________________ ripe-157.txt Page 5 ripe-157 A. M. R. Magee ____________________________________________________ Records in the RIPE Database are known as "objects". Each object describes a single entity in internet operations. This implies that information about that entity should only be contained in the corre- sponding database object and should not be repeated in other objects. The phrase "RIPE Database" is often used to refer to the interface software, rather than the information that is stored in the database. In ambiguous situa- tions, it will made clear what is being discussed at any time. Objects are composed of pairs of attributes and val- ues e.g. the "person" object is composed of the following attributes: person address phone fax-no e-mail nic-hdl remarks notify mnt-by changed source Each of these attributes has a value, e.g. person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 970114 source: RIPE Similarly, the domain object, which represents a ____________________________________________________ ripe-157.txt Page 6 ripe-157 A. M. R. Magee ____________________________________________________ range of IP addresses, has the following attributes: domain descr admin-c tech-c zone-c nserver sub-dom dom-net remarks notify mnt-by mnt-lower changed source An example of a domain object is: domain: over.ripe.net descr: Network for ripe-dbm use. descr: RIPE Network Coordination Centre descr: Kruislaan 409 descr: NL-1098 SJ Amsterdam descr: The Netherlands admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE zone-c: AMRM1-RIPE mnt-by: AMRM1-RIPE-MNT changed: ripe-dbm@ripe.net 970115 source: RIPE It may be seen that some attributes may appear more than once. Such an attribute is called "multiple". If an attribute can only appear once, it is called "single". Some attributes must be in the object; these attributes are "mandatory"; otherwise they are "optional". Some attributes are no longer used; they are known as "obsolete". The RIPE Network Management Database is not a rela- tional database (cf. SQL/ORACLE, MS Access, MS Excel). However, there is some cross-referencing of the records; e.g. if you do a look-up of a domain ____________________________________________________ ripe-157.txt Page 7 ripe-157 A. M. R. Magee ____________________________________________________ object, you will also get the details of the admin- istrative contact person (the "admin-c") and the technical contact person (the "tech-c"). [These extra look-ups may be switched off, if preferred]. The objects and their description. The types of objects stored in the RIPE database are summarized in the following table: Rg = the registry involved Object = the name of the object in RIPE Database Describes = the entity in internet operations References = indicates the relation between the objects; IP = IP address allocation and assignment Registry; D = Domain Registry R = Routing Registry All = all three registries ____________________________________________________ ripe-157.txt Page 8 ripe-157 A. M. R. Magee ____________________________________________________ +----------------------------------------------------------------------------+ | Objects in the RIPE Database | +----+------------+--------------------------------+-------------------------+ |Rg | Object | Describes | References | +----+------------+--------------------------------+-------------------------+ |All | mntner | maintainer object | person, role, mailboxes | |All | person | contact persons | mntner | |All | role | role (e.g.help desk) | person, mntner | |IP | inetnum | IP address space | person, role, mntner | |IP | inet6num | IP version address space | person, role, mntner | |D | domain | DNS domain | person, role, mntner | |R | aut-num | autonomous system (AS) | person, role, mntner | | | | (aut-num,community) | | |R | as-macro | a group of autonomous systems | person, role, | | | | mntner, aut-num | | |R | community | a community of routes that | person, role, | | | | cannot be represented by an | mntner | | | | AS or a group of AS's | | |R | route | a route being announced | aut-num, community, | | | | | mntner | | | | | | |R | dom-prefix | CLNS address space and routing | person, role, mntner | |R | inet-rtr | router name | person, role, mntner | | | limerick | poetry | person, role, mntner | +----+------------+--------------------------------+-------------------------+ The first column indicates whether the object is part of the address registry (IP), the routing reg- istry (R), the domain registry (D) or all three. The last column indicates the types of objects ref- erenced in an object of this type. It can be seen that almost all objects reference contact persons. The policies and procedures of address space assign- ment indicated in ripe-140 should be followed when an address space assignment is being entered. Simi- larly, whenever a routing policy is being entered into the routing registry, the policies of ripe-181 should be followed. As stated earlier, the RIPE Database contains three registries and contact information. These will now be discussed. ____________________________________________________ ripe-157.txt Page 9 ripe-157 A. M. R. Magee ____________________________________________________ The IP address space allocation and assignment registry The objects in the IP Registry and their functions will now be described. The inetnum object: Here is an example of an inetnum object: inetnum: 193.0.0.0 - 193.0.0.255 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: DK143-RIPE tech-c: GJG1-RIPE rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops@ripe.net changed: orange@ripe.net 960815 changed: GeertJan.deGroot@ripe.net 970110 source: RIPE The inetnum attribute contains an address range specified in dotted quad notation, which is entered in the inetnum object. For example, if an organisa- tion is assigned a /22 address set for 1024 network addresses, the assigned range [e.g. 193.1.192.0 - 193.1.195.255], is put in the "inetnum" field of the inetnum object. The precise syntax allowed is spec- ified in detail in the Appendix A. To help identify this assignment in the RIPE database, a short, but semantically meaningful name is entered in the netname field. A short descrip- tion of the organisation that uses the assigned addresses is given. The information is specified using one or more descr fields in the Network Tem- plate. If, for example, the assigned addresses will be used by the Department of Neural Surgery at Cata- tonic State University, then the department and uni- versity names may be specified in two descr fields. The ISO 3166 country code should be specified in the country field. These country codes may be found at ftp://ftp.ripe.net/iso3166-countrycodes. The full country name can be used if the code is not known. ____________________________________________________ ripe-157.txt Page 10 ripe-157 A. M. R. Magee ____________________________________________________ The admin-c and tech-c fields are used to specify the Internet Registry handle (NIC handle) for the administrative and technical contact persons, respectively. The administrative person specified in the admin-c field must be physically located at the site of the network. The technical person spec- ified in the tech-c field may be a network support person located on site, but could also be a consul- tant who maintains the network for the organisation. In both cases, more than one person can be speci- fied. The use of NIC handles to specify each con- tact person is required, as it ensures each person has a unique entry in the database. If the person doesn't have an entry in the database, a unique NIC handle can be obtained using an automatic process; see Section 2.2. For security purposes, a notify field can be filled out with an e-mail address to be notified when changes are made to the database object and a mnt-by field can reference a maintainer object which desig- nates who can make changes to the object. The status field can have one of these values: ALLOCATED PA (the most common allocation type for Local IR's) ALLOCATED PI (rare for Local IR's) ALLOCATED UNSPECIFIED ASSIGNED PA ASSIGNED PI These five values are explained in ripe-140. Below is the template of the inetnum object: ____________________________________________________ ripe-157.txt Page 11 ripe-157 A. M. R. Magee ____________________________________________________ inetnum: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [look-up key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] rev-srv: [optional] [multiple] [ ] status: [optional] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] mnt-lower: [optional] [multiple] [ ] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] The flags "mandatory", "single", "look-up key" etc. are explained in Section 2.1.1, The "-t" option. The Domain Registry: There is only one type of object in this registry; the domain object. This object represents Top Level Domain (TLD) and other domain registrations. It is also used for Reverse Delegations. The domain name is written in fully qualified format, without trailing "." . An example of a domain object is shown below: domain: over.ripe.net descr: RIPE Network Coordination Centre descr: Kruislaan 409 descr: NL-1098 SJ Amsterdam descr: The Netherlands admin-c: HC56-RIPE tech-c: AMRM1-RIPE zone-c: AMRM1-RIPE mnt-by: AMRM-TEST changed: ripe-dbm@ripe.net 970115 source: RIPE ____________________________________________________ ripe-157.txt Page 12 ripe-157 A. M. R. Magee ____________________________________________________ The template of the domain object is given below: domain: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] zone-c: [mandatory] [multiple] [inverse key] nserver: [optional] [multiple] [ ] sub-dom: [optional] [multiple] [ ] dom-net: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] mnt-lower: [optional] [multiple] [ ] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] The Routing Registry: The objects in the Routing Registry are: aut-num (autonomous system), route, as-macro (autonomous system macro), community, dom-prefix (clns [connectionless network service] address space and routing object), inet-rtr (router name). The RIPE Routing Registry was developed as part of the PRIDE project at the RIPE NCC and was based on the architecture of the RIPE database. It is, like the IP address allocation registry, a sub-set of the information in the RIPE database. The definitive document on the RIPE Routing Registry is Ripe-181. Ripe-181 became RFC1786. The aut-num (Autonomous System, AS) object: 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 pol- icy. 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 AS's. ____________________________________________________ ripe-157.txt Page 13 ripe-157 A. M. R. Magee ____________________________________________________ The term AS is often confused or even misused as a convenient way of grouping together a set of net- works 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. AS's can strictly have only one single external routing policy. An example of an aut-num object is: aut-num: AS3333 descr: RIPE NCC descr: European Regional Internet Registry as-in: from AS286 120 accept ANY as-in: from AS1103 120 accept ANY [.........stuff deleted.........] as-out: to AS286 announce AS3333 as-out: to AS1103 announce AS3333 as-out: to AS1104 announce AS3333 [.........stuff deleted.........] admin-c: DK143-RIPE tech-c: GJG1-RIPE tech-c: DK143-RIPE mnt-by: AS3333-MNT changed: GeertJan.deGroot@ripe.net 970114 source: RIPE The template of the aut-num object is: aut-num: [mandatory] [single] [primary/look-up key] 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] [ ] guardian: [optional] [single] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] The route object: ____________________________________________________ ripe-157.txt Page 14 ripe-157 A. M. R. Magee ____________________________________________________ The route object is used to represent a single route injected into the Internet routing mesh. There are several important aspects of the attributes worthy of note. The value of the route attribute is a classless address. It represents the exact route being injected into the routing mesh. 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 above) thus referenced provides all the contact information for this route. Special cases: There can only be a single originat- ing AS in each route object. However in today's Internet sometimes a route is injected by more than one AS. This situation is poten- tially dangerous as it can create conflicting routing policies for that route and requires coordi- nation between the originating AS's. In the routing registry this is represented by multiple route objects. This is a departure from the one route (net), one AS principle of the ripe-181 routing registry. ____________________________________________________ ripe-157.txt Page 15 ripe-157 A. M. R. Magee ____________________________________________________ An example of a route object is: route: 193.0.0.0/24 descr: RIPE-NCC origin: AS3333 notify: ops@ripe.net mnt-by: RIPE-NCC-MNT changed: GeertJan.deGroot@ripe.net 960812 source: RIPE The template of the route object is: route: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] origin: [mandatory] [single] [primary key] hole: [optional] [multiple] [ ] withdrawn: [optional] [single] [ ] comm-list: [optional] [multiple] [ ] advisory: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] The as-macro object: It may be difficult to keep track of each and every new AS that is represented in the routing reg- istry. A convenient way around this is to define an `AS Macro' which is a convenient way to group AS's. This is done so the maintainer of an AS object does not have to add a new AS to its routing policy as described by the as-in and as-out attributes of their AS object. An `AS Macro' is a group of autonomous systems with the same routing policies. An AS-Macro can be used in for the "as-in" and "as-out" attributes in the aut-num object. The AS-Macro object is then used to derive the list or group of AS's. ____________________________________________________ ripe-157.txt Page 16 ripe-157 A. M. R. Magee ____________________________________________________ An example of an as-macro object is: as-macro: AS-EBONE descr: EBONE AS's as-list: AS378 AS513 AS517 AS544 AS789 AS2060 AS3334 AS3293 [.......................stuff deleted.............................] as-list: AS6703 AS6740 AS6827 AS6867 AS6765 AS5608 AS6761 AS6866 as-list: AS-TIPNET AS-BTGB AS-BTTRANSIT AS-ACONET AS-DEMON as-list: AS-TAIDE AS-TELIANET AS-TMPEBONECWIX guardian: staff@ebone.net tech-c: BC83-RIPE admin-c: BE10 mnt-by: EBONE-MNT changed: bc@sunet.se 970115 source: RIPE The template of the as-macro object is: as-macro: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] as-list: [mandatory] [multiple] [ ] guardian: [optional] [single] [ ] tech-c: [mandatory] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] The community object: A community is a group of routes that cannot be rep- resented by an AS or a group of AS's. It is in some circumstances useful to define a group of routes that have something in common. This could be a spe- cial access policy to a supercomputer centre, a group of routes used for a specific mission, or a disciplinary group that is scattered among sev- eral autonomous systems. Also these communities could be useful to group routes for the purpose of network statistics. Communities do not have a common routing policy. Communities do not exchange routing information, since they do not represent an autonomous sys- tem. More specifically, communities do not define routing policies, but access or use policies. ____________________________________________________ ripe-157.txt Page 17 ripe-157 A. M. R. Magee ____________________________________________________ However, they can be used as in conjunction with an AS's routing policy to define a set of routes for which the AS sets routing policy. An example of a community object is given below: community: HEPNET descr: High Energy Physics Network authority: HEPnet technical committee IP (HTC-IP) guardian: farrache@ccpnxt5.in2p3.fr tech-c: Gilles Farrache admin-c: Gilles Farrache changed: farrache@ccpnxt5.in2p3.fr 940222 source: RIPE The template of the community object is: community: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] authority: [mandatory] [single] [ ] guardian: [optional] [single] [ ] tech-c: [mandatory] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] More details on community objects may be found in ripe-181. ____________________________________________________ ripe-157.txt Page 18 ripe-157 A. M. R. Magee ____________________________________________________ The dom-prefix object: This object is used for ConnectionLess Network Ser- vice (CLNS) representation. The template of this object is: dom-prefix: [mandatory] [single] [primary/look-up key] dom-name: [mandatory] [single] [look-up key] descr: [optional] [multiple] [ ] bis: [optional] [multiple] [ ] dom-in: [optional] [multiple] [ ] dom-out: [optional] [multiple] [ ] default: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [ ] tech-c: [mandatory] [multiple] [ ] guardian: [optional] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] The inet-rtr object: This object represents an internet router. See ripe-122 for more details. The template of this object is: inet-rtr: [mandatory] [single] [primary/look-up key] localas: [mandatory] [single] [ ] ifaddr: [mandatory] [multiple] [look-up key] peer: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] ____________________________________________________ ripe-157.txt Page 19 ripe-157 A. M. R. Magee ____________________________________________________ Contact Information The person object: The person's name is specified in full in the person field. The full postal address is specified using multiple address fields. The international tele- phone number which can be used to reach the person at work is entered in the phone field, and the fax number is entered in the fax-no field. The NIC han- dle for this person is entered in the nic-hdl field to uniquely identify this person in the database. As with the network template, a notify field can be filled out with an e-mail address to be notified when changes are made to the database object and a mnt-by field can reference a maintainer object which designates who can make changes to the object. See Section 2.3 for further details on maintainer objects. An example of a person object is: person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 970115 source: RIPE The template of the person object is: person: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [look-up key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] ____________________________________________________ ripe-157.txt Page 20 ripe-157 A. M. R. Magee ____________________________________________________ The role object The role object is similar to the person object. It cannot be referenced in an admin-c field. However, it has an attribute, "trouble", which may be used to give information on contacting operations staff. An example of a role object is: role: RIPE DBM address: Amsterdam e-mail: ripe-dbm@ripe.net trouble: Information: http://www.ripe.net/db/index.html trouble: Documentation: http://www.ripe.net/docs/ripe-157.html trouble: Questions and bug reports ... mailto:ripe-dbm@ripe.net admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE nic-hdl: RD132-RIPE mnt-by: RIPE-DBM-MNT changed: ripe-dbm@ripe.net 970115 changed: ripe-dbm@ripe.net 19970429 source: RIPE The template of a role object is: role: [optional] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] trouble: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Note that URL's may be included in the "remarks" attribute. These are interpreted as links on the Web interface to the RIPE Database. The mntner object: ____________________________________________________ ripe-157.txt Page 21 ripe-157 A. M. R. Magee ____________________________________________________ Objects in the RIPE database may be protected using mntner objects. The mntner (or maintainer) object contains details of who is authorised to make changes to objects and details of a process that actually verifies that the person who makes the changes is authorised to do so. An example of a mntner object is: mntner: AMRM1-RIPE-MNT descr: Ambrose's mntner. admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE upd-to: ambrose@ripe.net mnt-nfy: ambrose@ripe.net mnt-nfy: ripe-dbm@ripe.net auth: CRYPT-PW otpbdphttaoas remarks: This is a test mntner. notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 970115 source: RIPE The template of the mntner object is: mntner: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] upd-to: [mandatory] [multiple] [ ] mnt-nfy: [optional] [multiple] [ ] auth: [mandatory] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Attributes used in all objects. In all objects, space is reserved to identify the person submitting these entries to the registry database. Their e-mail address must be specified in the "changed" field together with the date the tem- plate is submitted. Similarly, the "source" field is used to specify the registry database where the requester information can be found after an assignment is made. Usually, ____________________________________________________ ripe-157.txt Page 22 ripe-157 A. M. R. Magee ____________________________________________________ it is RIPE. Details of attributes and objects may be found in the Appendix*. There are ways of obtaining the for- mat or template of an object; these are discussed in Section 2. 1.3 Management of the database objects: In principle, anyone can create, change or delete objects in the RIPE Database using electronic mail. E-mail is sent to , which is an "automatic" mailbox. The entire record or object must be in the body of the message, not only the attributes to be changed. More than one object may be in the message, but objects must be separated by at least one blank line. An acknowledgement message will be sent to you auto- matically once the update is complete. If a syntax error in your request is detected or if special authorization is required for a particular request, you will receive an appropriate error message. You will always receive a reply. If you do not receive any reply, it implies that the mail has bounced or been lost. E-mail updates are sent to an automatic mailbox which handles update requests. When mail is sent to this address it is analysed, authorization checks are performed and finally the actual updates, if appropriate, are done. In some cases, the request must be sent to a human mailbox. For security reasons, a request to create a mntner ("maintainer") object must be sent to . However, requests to change or delete a mntner object should be sent to . If a request to create a mntner is sent to , it will be forwarded to . This will be discussed further in Section 2.3. ____________________________________________________ ripe-157.txt Page 23 ripe-157 A. M. R. Magee ____________________________________________________ Chapter 2; Database queries and updates: 2.1 Querying the RIPE Database There are five ways of querying the RIPE database: whois client, WWW, WAIS, telnet and e-mail. The choice of which one to use depends on what resources are available at your site and which one your find the most appropriate. Each way of querying the database will now be explained. 2.1.1 RIPE whois client: Searching for the names of database objects; If you wish to look up objects in the RIPE database, you must use special search keys. A full list of the search keys is given below: OBJECT KEYS ----------------------------------------------------------------------------------- aut-num AS number (e.g. AS3333) as-macro as-macro name (e.g. AS-EBONE) community community name (e.g. HEPNET) domain domain name (e.g. over.ripe.net) inetnum range of IP addresses e.g 193.0.0.0 - 193.0.0.255; network name e.g.RIPE-NCC inet6num range of IP version 6 addresses or network name person a person's name or NIC-handle or e-mail address in RFC822 format. e.g. Ambrose Magee or AMRM1-RIPE or ambrose@ripe.net clns object domain-prefix domain-prefix, domain-name inet-rtr internet router name (e.g. limerick name of limerick mntner name of mntner object e.g. AMRM1-RIPE-MNT route internet route e.g. 193.0.0.0/24 role the name, the NIC-handle or the e-mail address (in RFC822 format) of a role object; e.g. RIPE NCC ____________________________________________________ ripe-157.txt Page 24 ripe-157 A. M. R. Magee ____________________________________________________ If you also want to search for other strings in the objects, you can use the WAIS interface; however it doesn't support the special options that are pro- vided in the RIPE 'whois' interface. The RIPE whois client has several options, which may be used either alone or in combination. The following is a list, in alphabetical order, of the available options, which are explained in more detail below. Option Function ------------------------------------------------------------------------------ -a search all databases -F fast raw output (implies -Fr) -h search alternate server -i inverse look-up -k used with the telnet interface -L find all Less specific matches -m find first level More specific matches -M find all More specific matches -p connect to other port than the default whois port -r turn off recursive lookups -s search databases with source "source" -S tell server to leave out "syntactic sugar" -t requests template for object of type "type" -T only look for objects of type "type" -HELP gives a copy of the current `HELP & HOWTO' document. A very useful option is "-h", which allows you to connect directly to the server at the RIPE NCC or to a "mirror" of the RIPE database elsewhere. - Example: $ whois -h whois.ripe.net AMRM1-RIPE -a option: This allows you to search all the databases that are mirrored by the RIPE NCC. In some cases, only part of a particular database is mirrored e.g. only the records of autonomous systems. The following databases are currently mirrored: ____________________________________________________ ripe-157.txt Page 25 ripe-157 A. M. R. Magee ____________________________________________________ RADB (autonomous systems, IP address assignments, mntner objects, routes, internet routers) InterNIC (autonomous systems, IP address assign- ments) ANS (autonomous system macros, mntner objects, routes, internet routers) MCI (autonomous system macros, mntner objects, con- tact persons, routes, internet routers, IP address assignments) CANET (routes, autonomous systems, mntner objects, internet routers) APNIC (all RIPE type objects) Example: [an-lar] $ whois -h whois.ripe.net -a David Conrad person: David Conrad address: Asia Pacific Network Information Center [..... stuff deleted .....] source: APNIC -F option: This option generates an output quickly, but with the abbreviated form of the attributes. Example: [an-lar]$ whois -h whois.ripe.net AMRM1-RIPE gives ____________________________________________________ ripe-157.txt Page 26 ripe-157 A. M. R. Magee ____________________________________________________ person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM-RIPE-MNT changed: ambrose@ripe.net 970115 source: RIPE However, [an-lar]$ whois -F -h whois.ripe.net AMRM1-RIPE gives *pn: Ambrose Magee *ad: RIPE Network Co-ordination Centre (NCC) *ad: Kruislaan 409 *ad: NL-1098 SJ Amsterdam *ad: The Netherlands *ph: +31 20 592 5065 *fx: +31 20 592 5090 *em: ambrose@ripe.net *nh: AMRM1-RIPE *ny: ambrose@ripe.net *mb: AMRM-RIPE-MNT *ch: ambrose@ripe.net 970115 *so: RIPE -i option: This option allows you to do reverse or inverse look-ups of particular combinations of attributes and objects. The attributes which can be used are: admin-c, tech-c, zone-c; notify; origin; mnt-by; author. ____________________________________________________ ripe-157.txt Page 27 ripe-157 A. M. R. Magee ____________________________________________________ The syntax of the usage is: whois -i Examples of how the "-i" option is used are now given: * whois -i admin-c,tech-c,zone-c [an-lar]$ whois -h whois.ripe.net -i admin-c,tech- c,zone-c CO19-RIPE finds all objects which cite CO19-RIPE as an admin-c or a tech-c or a zone-c. inetnum: 193.0.0.0 - 193.0.255.255 netname: EU-ZZ-193-0 descr: European Regional Registry descr: Europe country: EU admin-c: MK16-RIPE tech-c: CO19-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: hostmaster@ripe.net 970506 source: RIPE inetnum: 193.203.0.0 - 193.203.255.255 netname: EU-ZZ-193-203 descr: European Regional Reg- istry [.......stuff deleted.......] Any one or more of the three attributes admin-c, tech-c and zone-c may be used. * whois -i notify You can also find all objects which have a particu- lar e-mail address in their "notify" attribute; Example: ____________________________________________________ ripe-157.txt Page 28 ripe-157 A. M. R. Magee ____________________________________________________ [an-lar]$ whois -h whois.ripe.net -i notify ambrose@ripe.net finds all objects which have ambrose@ripe.net in their notify attribute. mntner: AMRM1-RIPE-MNT descr: Ambrose's mntner. admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE upd-to: ambrose@ripe.net mnt-nfy: ambrose@ripe.net mnt-nfy: ripe-dbm@ripe.net auth: MAIL-FROM Ambrose.Magee@ripe.net auth: MAIL-FROM ripe-dbm@ripe.net remarks: This is a test mntner. notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 960815 changed: ambrose@ripe.net 960930 source: RIPE person: Ambrose Magee [.......stuff deleted.......] * whois -i origin Example: [an-lar]$ whois -h whois.ripe.net -i origin AS3333 finds all route objects which specify AS3333 as their origin. route: 193.0.0.0/24 descr: RIPE-NCC origin: AS3333 notify: ops@ripe.net mnt-by: RIPE-NCC-MNT changed: GeertJan.deGroot@ripe.net 960812 source: RIPE * whois -i mnt-by ____________________________________________________ ripe-157.txt Page 29 ripe-157 A. M. R. Magee ____________________________________________________ Example [an-lar] $ whois -h whois.ripe.net -i mnt-by AMRM1-RIPE-MNT finds all objects which are maintained by AMRM1-RIPE-MNT. (See Section 2.3 for details on mntner objects). * whois -i author Example: [an-lar]$whois -h whois.ripe.net -i author AMRM1-RIPE finds all limericks with AMRM1-RIPE in the "author" attribute. [an-lar]$whois -h whois.ripe.net -i author Ambrose Magee finds all limericks with "Ambrose Magee" in the "author" attribute. The "-r" option: All the above options do recursive look-ups i.e. they will look-up any person objects associated with admin-c, tech-c, zone-c or author attributes. To disable this recursive look-up, use the "-r" option. This may be used with the other options, including "-i". Example: [an-lar]$ whois -h whois.ripe.net -r -i admin- c,tech-c,zone-c AMRM1-RIPE Note that the "-r" flag must precede the "-i" flag and the arguments. -k option: This is used in the telnet interface. See Section 2.1.4(b) ____________________________________________________ ripe-157.txt Page 30 ripe-157 A. M. R. Magee ____________________________________________________ -L option: Sometimes when doing a look-up on an inetnum object, you may wish to find the "next objects up" in the hierarchy i.e. all less specific matches; e.g. [an-lar]$ whois -h whois.ripe.net -r 193.1.0.0/16 inetnum: 193.1.0.0 - 193.1.255.255 netname: IE-HEANET-193-1 descr: DELEGATED BLOCK descr: Provider Local Registry descr: HEAnet country: IE admin-c: MN131 tech-c: MN131 mnt-by: RIPE-NCC-HM-MNT changed: roderik@ripe.net 950315 source: RIPE Now compare the above with the output of the follow- ing: [an-lar]$ whois -h whois.ripe.net -r -L 193.1.0.0/16 gives ____________________________________________________ ripe-157.txt Page 31 ripe-157 A. M. R. Magee ____________________________________________________ inetnum: 193.1.0.0 - 193.1.255.255 netname: IE-HEANET-193-1 descr: DELEGATED BLOCK descr: Provider Local Registry descr: HEAnet country: IE admin-c: MN131 tech-c: MN131 mnt-by: RIPE-NCC-HM-MNT changed: roderik@ripe.net 950315 source: RIPE inetnum: 193.0.0.0 - 193.255.255.255 netname: EU-ZZ-193 descr: European Regional Registry descr: Europe country: EU admin-c: DK58 tech-c: DK13-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT changed: hostmaster@ripe.net 960123 source: RIPE In other words, the inetnum object which "includes" IE-HEANET-193-1, is also found. The same process is implemented for route objects, but not for domain objects. There is no "-l" option. The default behaviour of the database is to find exactly the object you want or first less specific match (for inetnum and route objects). -m option: This option allows you to look-up all those objects which are one level more specific than what you have given in your query. In the case of inetnum objects, this means that you can lookup all those inetnum objects which are the "children" of the inetnum object found by an exact match i.e. the first level more specific match. Example: [an-lar]$ whois -h whois.ripe.net -r 193.1.0.0/16 ____________________________________________________ ripe-157.txt Page 32 ripe-157 A. M. R. Magee ____________________________________________________ inetnum: 193.1.0.0 - 193.1.255.255 netname: IE-HEANET-193-1 [.......stuff deleted.......] But, [an-lar]$ whois -h whois.ripe.net -r -m 193.1.0.0/16 finds 86 objects; i.e. there are 86 objects which are directly within the range of IP addresses given by 193.1.0.0 - 193.1.255.255. -M option: Some of the objects found by a "-m" look-up have "children" themselves; i.e. there are objects directly within the range of IP addresses specified by the objects found by a "-m" look-up. These objects may be found by a "-M" look-up. Example: [an-lar]$ whois -h whois.ripe.net -r -M 193.1.0.0/16 finds 97 objects. -p option: Normally, when you do a "whois" query, you connect to port 43 of the server which you specified with the "-h" option. However, there are occasions when you wish to connect to a port different from the default port. E.g., if you had a private database, with a whois daemon of its own, you could connect to it. [an-lar]$ whois -h localhost -p 4327 connects to port 4327 on the localhost. -s option: The RIPE database contains objects that are from other databases. This is indicated by the "source" attribute in each object. The sources used in the RIPE database are RIPE, RADB, INTERNIC, ANS, MCI, CANET and APNIC. Not every object type may be found using a source other than RIPE. See the details for option "-a". ____________________________________________________ ripe-157.txt Page 33 ripe-157 A. M. R. Magee ____________________________________________________ Example: [an-lar]$ whois -h whois.ripe.net -s INTERNIC AS3333 gives aut-num: AS3333 descr: part of AS block AS3154 - AS3353 admin-c: 3353 remarks: this AS number is assigned by the InterNIC remarks: please query whois.internic.net for more information changed: ripe-dbm@ripe.net 970103 source: INTERNIC -S option: This option tells the server to leave out text which is only added to make aut-num objects more readable by humans. This text is called "Syntactic Sugar". Example: [an-lar]$ whois -h whois.ripe.net -r AS3333 gives aut-num: AS3333 descr: RIPE NCC descr: European Regional Internet Registry as-in: from AS286 120 accept ANY [........stuff deleted ........] as-out: to AS286 announce AS3333 [........stuff deleted ........] Compare with the output of [an-lar]$ whois -h whois.ripe.net -r -S AS3333 aut-num: AS3333 descr: RIPE NCC descr: European Regional Internet Registry as-in: AS286 120 ANY [........stuff deleted ........] as-out: AS286 AS3333 [........stuff deleted ........] ____________________________________________________ ripe-157.txt Page 34 ripe-157 A. M. R. Magee ____________________________________________________ The "-t" option: This option allows you to obtain a template of any type of object that is accepted by the RIPE database. You may specify either the full or the abbreviated name of the object as follows: Full name Abbreviation -------------------------- aut-num an as-macro am community cm domain dn inetnum in inet6num i6 persons pn dom-prefix dp inet-rtr ir limerick li mntner mt route rt role ro -------------------------- A full list of objects may be obtained by typing "all" after the "-t" option. The -t option generates a template that lists each of the attributes together with a list of its flags. Flags are enclosed in square brackets and separated within the list by white space. ____________________________________________________ ripe-157.txt Page 35 ripe-157 A. M. R. Magee ____________________________________________________ The flags are ... [mandatory] - An object MUST NOT contain zero instances of this attribute. [optional] - An object MAY contain zero instances of this attribute. [single] - An object MUST NOT contain more than one instance of this attribute. [multiple] - An object MAY contain more than one instance of this attribute. [look-up key] - Attribute is indexed. [inverse key] - Attribute is in the 'reverse' index. (use -i) [primary key] - Attribute is (part of) the primary key. [primary/look-up key] - Attibute is both indexed and is (part of) the primary key. The "-t" option does not display a list of obsolete attributes, as before. The "-v" option must be used. Example: [an-lar]$ whois -h whois.ripe.net -t person person: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [look-up key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] [an-lar]$ whois -h whois.ripe.net -t pn gives the same output. ____________________________________________________ ripe-157.txt Page 36 ripe-157 A. M. R. Magee ____________________________________________________ The "-v" option: This option displays a detailed ("verbose") template of any type of object that is accepted by the RIPE database. Each attribute of the object is briefly described. A full list of objects is available by typing "all" after the "-v" option. Example: [an-lar] whois -h whois.ripe.net -v person The person object: The person object contains information on how to contact those people who are responsible for network operations or RIPE Database objects. person: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] [...........Remainder of basic template deleted............] The content of the attributes of the person object are defined below: person The full name of an adminstrative, technical or zone contact person specified in another object. [..........Remainder deleted......................] Note: obsoleted attributes are only displayed using the "-v" option. The "-T" option: If you know the type of the object for which you are looking, you can restrict the search to that type only. This option is useful when different types of object have the same KEYS. Example: ____________________________________________________ ripe-157.txt Page 37 ripe-157 A. M. R. Magee ____________________________________________________ [an-lar]$ whois -h whois.ripe.net -r 193.0.0.0/24 gives inetnum: 193.0.0.0 - 193.0.0.255 netname: RIPE-MEETING descr: RIPE Meeting Terminal Room descr: Amsterdam, Netherlands country: NL admin-c: GJG1-RIPE tech-c: GJG1-RIPE changed: GeertJan.deGroot@ripe.net 970110 source: RIPE route: 193.0.0.0/24 descr: RIPE-NCC origin: AS3333 notify: ops@ripe.net mnt-by: RIPE-NCC-MNT changed: GeertJan.deGroot@ripe.net 960812 source: RIPE cf. the output of [an-lar] $ whois -h whois.ripe.net -r -T inetnum 193.0.0.0/24 inetnum: 193.0.0.0 - 193.0.0.255 netname: RIPE-MEETING descr: RIPE Meeting Terminal Room descr: Amsterdam, Netherlands country: NL admin-c: GJG1-RIPE tech-c: GJG1-RIPE changed: GeertJan.deGroot@ripe.net 970110 source: RIPE In this situation, only the inetnum object is found. Note that when using the "-T" option, the abbrevi- ated form of the object names may be used; e,g, "in" can be used instead of "inetnum". -HELP option: The output of this option is an up-to-date copy of the HELP document for using the "whois" tools to access the RIPE database. ____________________________________________________ ripe-157.txt Page 38 ripe-157 A. M. R. Magee ____________________________________________________ Example: [an-lar]$ whois -h whois.ripe.net HELP gives This is an extract from Chapter 2 of ripe-157, which is available from: Database queries and updates: 2.1 Querying the RIPE Database [...stuff deleted...] Summary The syntax of the usage of the "whois" command is as follows: Usage: whois [-aFLmMrSv] [-h hostname] [-s sources] [-T types] [-i attr] keys whois -t type whois -v type Using non-RIPE `whois' clients: Please note that most of the options are NOT under- stood by non RIPE 'whois' client programs. Some- times the following work-around will work : Instead of [an-lar] $ whois -h whois.ripe.net -T person AMRM1-RIPE you can use [an-lar] $ whois -h whois.ripe.net "-T person AMRM1-RIPE" ____________________________________________________ ripe-157.txt Page 39 ripe-157 A. M. R. Magee ____________________________________________________ 2.1.2 WWW: http://www.ripe.net/db/ This is a web-based interface to the whois server; therefore you can only do a search on the KEYS listed in Section 2.1.1 2.1.3 WAIS: You should create a directory with a name like "wais-sources". In this directory, you can put all source files for WAIS applications. You should then create a file with a name like "ripe-database.src". The contents of the file should be this: (:source :version 3 :ip-name "wais.ripe.net" :tcp-port 210 :database-name "ripe-database" :cost 0 :cost-unit :free :maintainer "ripe-dbm@ripe.net" :description "This WAIS database contains the RIPE Network Management Database which is also available at: ftp://ftp.ripe.net/ripe/dbase") Now at your command line prompt, type "swais". You will now see a menu ("Source Selection") and a list of all the sources in your wais-sources directory. Follow the instructions. Note that you can search for any keyword, including addresses and telephone numbers. The "q" character allows to close the process: "?" gives you a list of all the keywords. ____________________________________________________ ripe-157.txt Page 40 ripe-157 A. M. R. Magee ____________________________________________________ Web interface to WAIS A Web interface to the RIPE Database WAIS server is available at http://www.ripe.net/db/dbwais.html 2.1.4 telnet There are currently two ways to telnet to the RIPE Database. (a) The first is to simply telnet "whois.ripe.net" and enter one of the options listed in Section 2.1.1(b), followed by one of the KEYS listed in Sec- tion 2.1.1(a). You are not required to type "whois". Example: [an-lar]$ telnet whois.ripe.net gives Trying 193.0.0.198... Connected to bsdbase.ripe.net. Escape character is '^]'. ******************************************************************** * RIPE NCC * * Telnet-Whois Interface to the RIPE Database * * Most frequently used keys are: IP address or pre- fix (classless), * network name, persons last, first or complete name, NIC handle, * and AS. * * Use 'help' as key to get general help on the RIPE database. * Contact for further help or to report problems. ******************************************************************** Enter search key [q to quit]: Ambrose Magee person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) ____________________________________________________ ripe-157.txt Page 41 ripe-157 A. M. R. Magee ____________________________________________________ [....stuff deleted....] Enter search key [q to quit]: -T route 193.0.0.0/23 route: 193.0.0.0/23 [....stuff deleted....] Enter search key [q to quit]: q Connection closed by foreign host. [an-lar]$ (b) The second is to telnet to "whois.ripe.net 43". This is a very basic interface to the whois server. You do not type "whois" in your query; you only type the whois option (e.g. "-r") and then the KEY. Example: [an-lar] $ telnet whois.ripe.net 43 gives Trying 193.0.0.198... Connected to bsdbase.ripe.net. Escape character is '^]'. -T rt 193.0.0.0/23 route: 193.0.0.0/23 [....stuff deleted....] Connection closed by foreign host. The connection is closed immediately after one query. If you wish to do more than one look-up dur- ing the same telnet session, you should use the "-k" option as shown: Example: Trying 193.0.0.198... Connected to bsdbase.ripe.net. Escape character is '^]'. -k -T rt 193.0.0.0/24 % Server is running at low priority for -M, -m and -k queries route: 193.0.0.0/24 descr: RIPE-NCC [....stuff deleted....] ____________________________________________________ ripe-157.txt Page 42 ripe-157 A. M. R. Magee ____________________________________________________ -r -T in 193.0.0.0/24 inetnum: 193.0.0.0 - 193.0.0.255 netname: RIPE-NCC [....stuff deleted....] -k Connection closed by foreign host. [an-lar] $ Note: "-k" is typed first, before any other charac- ters. Typing "-k" alone closes the session. 2.1.5 E-mail: (a) Send mail to with in the body text: whois KEY, where KEY is one of the KEYS from Section 2.1.1(a). "whois" must be at the beginning of a new line in the body of the message. Separate queries must be on separate lines. The "Subject:" line will not be interpreted. Example: An e-mail with the following in the body of the mes- sage whois 193.0.0.0/24 whois AMRM1-RIPE gets the following mail: > Dear mail whois user, > > The requested RIPE database queries gave the fol- lowing results: > > ------ > Query: 193.0.0.0/24 > > ____________________________________________________ ripe-157.txt Page 43 ripe-157 A. M. R. Magee ____________________________________________________ > inetnum: 193.0.0.0 - 193.0.0.255 > netname: RIPE-NCC > [.....stuff deleted.....] > > route: 193.0.0.0/24 > descr: RIPE-NCC > [.....stuff deleted.....] > > ------ > Query: AMRM1-RIPE > > > person: Ambrose Magee > address: RIPE Network Co-ordination Centre (NCC) > [.....stuff deleted.....] > > Regards > The RIPE NCC whois service (e-mail department) Important ! * This method doesn't support the whois options ! * Separate queries must be on separate lines. 2.1.6 Means of querying other databases To query the InterNIC database, use [an-lar] $ whois -h whois.internic.net All the databases that are mirrored by the RIPE NCC may be directly queried in this way. The databases that are mirrored are: RIPE, RADB, INTERNIC, ANS, MCI, CANET, APNIC ____________________________________________________ ripe-157.txt Page 44 ripe-157 A. M. R. Magee ____________________________________________________ 2.2 Creating, Updating and Deleting an Object: 2.2.1 Creating a new object: To create a new object, follow this procedure: * get the template; * modify the template; * send the object to the appropriate mailbox i.e. for new autonomous system objects, for new mntner objects and for all other objects. (1) Getting the template: Use whois -t . See Section 2.1.1 for details on how to obtain the template of any object. example [spoor] $ whois -h whois.ripe.net -t person gives person: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [look-up key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] (2) modification of the template; (i) Now fill in the appropriate details in the tem- plate. Do not leave attributes with values such as "[optional]", or "[multiple]". (ii) Attributes which are mandatory should .B not .R be empty. Otherwise, the update will be rejected by the database software. ____________________________________________________ ripe-157.txt Page 45 ripe-157 A. M. R. Magee ____________________________________________________ (iii) Attributes which are optional may be left empty, but they will be removed by the database software. Example: person: Ambrose Magee address: RIPE NCC Network Co-ordination Centre [.....stuff deleted.....] phone: +31 20 592 5065 fax: e-mail: ambrose@ripe.net [.....stuff deleted.....] The empty attribute "fax" will be deleted by the database software. Attributes which are described in the template as "single" must be on only one line. Attributes which are described as "multiple" may be on more than one line, but the attribute name must be at the beginning of each line. The "address" attribute in the person object is an example of an attribute that may be multiple. person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands [.....stuff deleted.....] (iv) If you are completing a person template or want to reference a person in an another object, you should use a RIPE handle ('nic-hdl:'). You can also use NIC handles from other registries such as the InterNIC if you are also registered there. NIC-han- dles will give you a unique identifier attached to a person which you can use as a reference. This avoids problems with different persons having the same name. You can get yourself a RIPE NIC-handle by putting the following in the NIC handle field: nic-hdl: AUTO-1 ____________________________________________________ ripe-157.txt Page 46 ripe-157 A. M. R. Magee ____________________________________________________ OR nic-hdl: AUTO-1YourInitials The second case advises the database software to use YourInitials (no more then 4 characters) for build- ing the NIC handle while the first case asks the database software to find the initials itself. You can use the same identifiers (AUTO-1 or AUTO-1YourInitials) in the same update message in other objects as a reference. The database software will then fill in the freshly assigned NIC handles in the objects. Note that you can also use other numbers (example: AUTO-2) so that you can update more person objects and objects that reference the persons in one E-mail message. Example: domain: perl.com admin-c: AUTO-1 tech-c: AUTO-2 [ ... stuff deleted ...] person: Ambrose Magee nic-hdl: AUTO-1 [ ... stuff deleted ...] person: Larry Wall nic-hdl: AUTO-2 [ ... stuff deleted ...] N.B. The same rules apply when obtaining a NIC-han- dle for a role object. (iv) Put today's date and your e-mail address in the "changed" attribute. The format of the date must be YYMMDD. (v) use of "mnt-by" attribute; You can protect your objects with maintainer objects by adding a `mnt-by:' attribute. For some objects this is even mandatory. Put the name of the main- tainer object in the "mnt-by" field Example: ____________________________________________________ ripe-157.txt Page 47 ripe-157 A. M. R. Magee ____________________________________________________ person: Ambrose Magee [....stuff deleted....] mnt-by: AMRM-MNT [.....stuff deleted.....] More information on maintainer objects may be found in Section 2.3. (vi) use of the keywords "NEW" and "ASSIGN"; You can ensure that the database will only accept your object if it is not already in the database by using the keywords "NEW" and "ASSIGN". Put "NEW" in the `Subject' line of your e-mail if you want the database to only accept new objects. Use the keyword "ASSIGN" if you want the database to only accept new inetnum objects. N.B. at the moment, these keywords are case insensi- tive. Avoid putting strings such as "Old person object with new address" or "Re-assign address space" in your `Subject' line. (3) send the object to the appropriate mailbox. : is an automatic mailbox and all e-mails that create, update or delete objects (see above for exceptions) should be sent to this address. If you require a detailed acknowledgement, put the keyword "LONGACK" in the `Subject' line of your e- mail. You will always receive an acknowledgement, even if "LONGACK" is not in the `Subject' line. If you do not receive an acknowledgement, the reason could be that your e-mail address is unknown and therefore the acknowledgement mail has bounced or has been lost. : Questions and bug reports should be sent to . You are recommended to send as much ____________________________________________________ ripe-157.txt Page 48 ripe-157 A. M. R. Magee ____________________________________________________ information as possible. 2.2.2 Updating an existing object: How to update an existing object This is done by sending in the new object. Probably the easiest way to do this is to get a copy of the old object, change or add the fields you want to change or add, and then put a new 'changed:' attribute in the object. Here are the steps in more detail: (1) Get a copy of the existing object; you can do this using whois -h whois.ripe.net >Temporary- File Example: [spoor] $ whois -h whois.ripe.net AMRM1-RIPE > update-file (2) Load the TemporaryFile into your favorite editor and make your changes or additions to the object. It is recommended to use NIC handles instead of the person names for references to person objects to guarantee that your object points to a single per- son. See Section 2.2.1 for more information. If you are updating a person or role object with a new or different NIC handle, or if you are updating a route object with a new or different origin, please note: it is wise to delete the old person, role or route object before adding the new objects for the follow- ing reasons: (a) the database will treat two person objects with the same name but with different NIC handles, as different objects; (b) the database will treat two person objects with the same name as different objects, if one object has a NIC-handle, but the other does not; (c) the database will treat route objects with the same "prefix length" representation, but with dif- ferent origins as different route objects; (d) the database handles role objects in the same way as it handles person objects. ____________________________________________________ ripe-157.txt Page 49 ripe-157 A. M. R. Magee ____________________________________________________ If you do not delete the old objects first, then the database will see the old and new objects as differ- ent objects and the update request will be treated as the creation of a new object instead of an update of the old object. The database will however recog- nize that a person object is an update if the only difference between the old and new object is that the old object did not have a NIC handle. (3) Add a "changed" attribute. This attribute has the following syntax : changed: E-mailAddress Date where 'E-mailAddress' is an RFC822 E-mail address specifying who made the change and 'Date' is the date of the change in either YYYYMMDD or YYMMDD for- mat. (4) Send your message to . (5) You will receive an acknowledgement. If you send in an object that is identical to one that is already in the database, the acknowledgement message will say "NOOP" meaning "NO OPeration"; i.e. the object in the database is not modified. 2.2.3 Deleting an object: This is done by sending in the whole object just like an update and adding a special attribute, 'delete', to it: delete: It is recommended that the reason for deleting the object be put as the value of the delete attribute. ____________________________________________________ ripe-157.txt Page 50 ripe-157 A. M. R. Magee ____________________________________________________ Example: person: Ambrose Magee 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: ambrose@ripe.net nic-hdl: AMRM2-RIPE notify: ambrose@ripe.net changed: ambrose@ripe.net 970110 source: RIPE delete: Duplicate person object. The deletion is only accepted if the object in the message is exactly the same as the one in the database about to be deleted. Please be very care- ful when deleting person or role objects unless you are sure that the person or role object is not ref- erenced by other objects. You can find objects that reference a certain person by doing a '-i' query; see Section 2.1.1. Example: [spoor] $ whois -h whois.ripe.net -r -i tech- c,admin-c,zone-c AMRM1-RIPE Some people might have used their name as a refer- ence instead of their NIC-handle, so you should also do a look-up on that. If you're not sure that you were the only one refer- encing a certain person object, do NOT delete that person object. It will not affect the database very much if there are some obsolete person objects. Authorization, notification and acknowledgement mes- sages for deletes are handled exactly the same way as for ordinary updates. 2.2.4 Warning and Error messages: The syntax of all objects sent to is rigorously checked. Acknowledge- ment messages are generated by these syntax checks. ____________________________________________________ ripe-157.txt Page 51 ripe-157 A. M. R. Magee ____________________________________________________ (a) You will always receive an acknowledgement that your update has been received. (b) If there are no mistakes in your update, you will receive an acknowledgement message saying "No errors were found in your update". (c) Minor, but not fatal mistakes will be corrected and the object will be accepted into the database. The acknowledgement message will indicate what cor- rection was made. Example: suppose this object is sent to . person: Ambrose Magee [.....stuff deleted.....] changed: ambrose@ripe.net The following warning message would be generated: WARNING: added current date to "changed" field. (d) Fatal mistakes will .B not .R be corrected and the object will .B not .R be accepted into the database. An acknowledgement message will be sent, which will identify the error. Example: suppose this object is sent to . ____________________________________________________ ripe-157.txt Page 52 ripe-157 A. M. R. Magee ____________________________________________________ route: 193.0.0.139/32 descr: x1.ripe.net origin: AS3333 changed: ambrose@ripe.net 961221 source: RIPE The following warning message would be generated: -------------------------------------------------------- Update FAILED: [route] 193.0.0.139/32 route: 193.0.0.139/32 descr: x1.ripe.net origin: AS3333 notify: ambrose@ripe.net changed: ambrose@ripe.net 961221 source: RIPE *ERROR*: mandatory field "mnt-by" missing Objects that just generated a WARNING have been updated as shown. Objects that generated an *ERROR* have NOT been updated as requested. Please re-submit corrected objects. ------------------------------------------------------------- (e) If you have any questions about any error mes- sages, you may send e-mail to . This mailbox is checked regularly. Please send as much information as possible. ____________________________________________________ ripe-157.txt Page 53 ripe-157 A. M. R. Magee ____________________________________________________ 2.3 Object Protection: Authorization and authentication: "Authorization" indicates only who has the authority to change database objects, but does not check that it is that person who is making the changes. "Authentication" actually verifies that the person who is making the changes is authorised to do so. 2.3.1. The "mntner" object: (a) This is an object which can be used to notify you of any changes to your objects and to allow only certain individuals to change your objects. The mntner object contains information on contact per- sons and on authentication and notification details. The mntner object is used every time a database object with a "mnt-by" attribute is created, updated or deleted to determine whether or not the origina- tor of the update request is authorised to make the update. Each mntner object should have an unique name. From now on, "mntner" and "maintainer" will be used interchangeably. Sometimes, the word "maintainer" refers to the human being referenced in the "mnt-nfy" attribute of the "mntner" object. In this document, "mntner" refers to the object and "maintainer" refers to the person. Adding a new mntner object must be authorised manu- ally by RIPE NCC staff. Details are given later. 2.3.2 Functionality: (i) Individual Object Protection: You can protect any object with a mntner object. All you have to do is include a "mnt-by" attribute in your object. For some objects, a "mnt-by" attribute is mandatory. The value of the "mnt-by" attribute is a mntner object which details of how changes to the object ____________________________________________________ ripe-157.txt Page 54 ripe-157 A. M. R. Magee ____________________________________________________ are to be authorised. Example: person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Kingdom of the Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 961220 source: RIPE The "mnt-by" attribute in the above object refers to this mntner object: mntner: AMRM1-RIPE-MNT descr: Ambrose's mntner. admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE upd-to: ambrose@ripe.net mnt-nfy: ambrose@ripe.net mnt-nfy: ripe-dbm@ripe.net auth: MAIL-FROM Ambrose.Magee@ripe.net remarks: This is a test mntner. notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 960815 changed: ambrose@ripe.net 960930 source: RIPE You can have more than one "mnt-nfy" attribute in a mntner object. Multiple mntner objects can be ref- erenced in objects by separating them with blank spaces or by using multiple mnt-by attributes per object. ____________________________________________________ ripe-157.txt Page 55 ripe-157 A. M. R. Magee ____________________________________________________ Example: person: Ambrose Magee [.....stuff deleted.....] mnt-by: AMRM1-RIPE-MNT RIPE-DBM-MNT [.....stuff deleted.....] or person: Ambrose Magee [.....stuff deleted.....] mnt-by: AMRM1-RIPE-MNT mnt-by: RIPE-DBM-MNT [.....stuff deleted.....] In this case all maintainers referenced are equally authorised to make changes to the object. When responding to queries, the RIPE whois server will not automatically give the associated mntner object that is referenced in the object for which you asked. i.e. you must look up the mntner object separately. Whenever a change to an object is attempted, the mnt-by attribute of the current database object is examined. The object may only be updated or deleted according to the authorisation scheme described in the associated mntner object. See Section 2.3.3. (ii) Notification of (Successful) Changes to objects that are protected by a mntner object: The "notify" attribute can be included in every object. It contains an e-mail address to which noti- fications of changes to the object itself will be sent. It is possible to put a "notify" attribute in all your objects. However, if the notify e-mail address is changed, then every object with a notify attribute that references that e-mail address will have to be updated. A more efficient approach is to include a "mnt-by" attribute in all your objects. This attribute will reference a mntner object, which itself has a "mnt- nfy" (maintainer notify) attribute. The value of this attribute is an e-mail address to which a noti- fication will be sent if any object maintained by ____________________________________________________ ripe-157.txt Page 56 ripe-157 A. M. R. Magee ____________________________________________________ this mntner object is added, updated 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 affect only one object. Whenever a change to an object is attempted the mnt- by attribute of the current database object is exam- ined. If there is no mnt-by attribute, the update always proceeds causing any notifications specified in notify attributes of the object. It is also a per- fectly legitimate authorisation model for those objects that do not need sophisticated authorisa- tion. Also we would like to stress that using stronger authorisation requires timely processing of update requests. An unresponsive maintainer prevent- ing others from making updates frequently is a worse solution than having no authorisation at all. If the update is originated by a maintainer refer- enced in a mnt-by attribute, the update also pro- ceeds causing the necessary notifications. There are various methods to authenticate the origin of an update request. These can be configured in the mntner object as described in Section 2.3.3. If a new object with a mnt-by attribute is added to the database or a mnt-by attribute is added to an object that previously had no such attribute, the authorisation step is performed on the maintainer to be added. If a database object has both a "notify" attribute and a "mnt-by" attribute, then two notification mes- sages will be generated. If both notifications are to be sent to the same e-mail address, then only one e-mail is sent, but it will contain two identical parts. E.g. Dear Colleague, This is to notify you that some object(s) in the RIPE Database which you either maintain or are listed as to-be-notified have been added, deleted or changed. The objects below are the old and new entries for these objects in the database. In case of DELETIONS, ____________________________________________________ ripe-157.txt Page 57 ripe-157 A. M. R. Magee ____________________________________________________ the deleted object is displayed. NOOPs are not reported. The update causing these changes had the following mail headers: - From: Ambrose Magee - Subject: LONGACK - Date: Tue, 17 Dec 1996 10:36:47 +0100 (MET) - Msg-Id: <199612170936.KAA10058@kantoor.ripe.net> RIPE Database Notification Department --- ____________________________________________________ ripe-157.txt Page 58 ripe-157 A. M. R. Magee ____________________________________________________ PREVIOUS OBJECT: person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose.magee@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 960920 changed: ambrose@ripe.net 961001 changed: ambrose@ripe.net 961217 source: RIPE REPLACED BY: person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Kingdom of the Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose.magee@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 960920 changed: ambrose@ripe.net 961001 changed: ambrose@ripe.net 961217 source: RIPE --- PREVIOUS OBJECT: person: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose.magee@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 960920 changed: ambrose@ripe.net 961001 changed: ambrose@ripe.net 961217 source: RIPE ____________________________________________________ ripe-157.txt Page 59 ripe-157 A. M. R. Magee ____________________________________________________ REPLACED BY: person: Ambrose Magee address: Ambrose Magee address: RIPE Network Co-ordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Kingdom of the Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: ambrose.magee@ripe.net nic-hdl: AMRM1-RIPE notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 960920 changed: ambrose@ripe.net 961001 changed: ambrose@ripe.net 961217 source: RIPE NOOP means "NO OPeration" i.e. the object was not changed. (iv) Notification of unauthorised attempts to change objects protected by a mntner: Any request to change an object protected by a mnt- ner must first satisfy the authorisation scheme given in the mntner. If the request does not sat- isfy these scheme, then it is forwarded to the mail- box given in the "upd-to" attribute of the mntner object. Whoever attempted the update is also noti- fied that this has occurred. No other notifications are sent in this case. There is another use of the mailbox specified in the "upd-to" attribute. If a person wishes to change an object, but is not authorised to do so, then the update should be sent to this mailbox. If an update is not authorised and no appropriate maintainer can be identified the request will be forwarded to the RIPE NCC for action. 2.3.3 Authorization schemes: This is specified using the "auth" attribute of the mntner object. The required scheme is specified ____________________________________________________ ripe-157.txt Page 60 ripe-157 A. M. R. Magee ____________________________________________________ here. Example: mntner: AMRM1-RIPE-MNT descr: Ambrose's mntner. admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE upd-to: ambrose@ripe.net mnt-nfy: ambrose@ripe.net auth: CRYPT-PW qlfichzrkkwgm remarks: This is a test mntner. notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 970115 source: RIPE There are three schemes; NONE, MAIL-FROM and CRYPT-PW The format is: 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 one auth attribute is specified any of them can be used alternatively for authentication of updates, i.e. specifying NONE and others does not make much sense. The auth attribute is not pro- tected information in any way; it is returned nor- mally like any attribute by the whois server and available 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 or on keeping this information secret. It is very difficult to keep the information confidential and thus the RIPE NCC cannot take this responsibility. The "NONE" scheme: With this scheme, any changes made are notified to the mailbox specified in the "mnt-nfy" field. There is no authentication i.e. anyone can make changes. ____________________________________________________ ripe-157.txt Page 61 ripe-157 A. M. R. Magee ____________________________________________________ However, if you are in doubt whether or not to change the object maintained (i.e. protected) by the mntner, you should send your request to the mailbox specified in the "upd-to" attribute. This is the simplest authentication scheme which is entirely backwards compatible with the one previ- ously used. No authentication is provided, i.e. it is assumed that all update requests originate from an authorised maintainer or are at least coordinated with one. Anyone in doubt whether it is OK to issue update requests should check with the maintainer concerned first, preferably at the mailbox speci- fied in the upd-to attribute. When making any changes the mnt-by attribute should not be changed without explicit consent from the current main- tainer. This scheme is for those who want to give everyone the possibility to make changes while at the same time using the mnt-by attribute for its notification and documentation features. A good reason to use this scheme is when the maintainer cannot guarantee timely processing of updates themselves. The "MAIL-FROM" scheme: This scheme checks the "From" line in the e-mail which contains the update. If it is the same as what is specified here, the update is allowed. This authentication method checks the content of the RFC822 From: header of an update request against the regular expression specified as . If the regular expression matches the content of the From: header the update request is authenticated success- fully. The regular expres- sions supported are described in POSIX 1003.2 sec- tion 2.8. As it is expected that most regular expressions will either be literals or of a form similar to .*@some.domain.or.other an extensive description of the possibilities will not be given. Note that the matching is applied to the whole con- tent of the From: header including comments if present. No attempt is made to isolate the mailbox part. It should be stressed that this authentication scheme is very weak. Forging RFC822 headers does not take much effort or ingenuity. The reason for the scheme's existence is that it easily pre- vents accidental updates rather than allowing them ____________________________________________________ ripe-157.txt Page 62 ripe-157 A. M. R. Magee ____________________________________________________ first and fixing them later when notified. This scheme is for those who want to prevent acci- dental updates by others and are able to process update requests in a timely manner. The "CRYPT-PW" scheme: This uses an encryption process which is similar to that used to make and check login passwords in UNIX. A password is chosen by the user; this is encrypted and put in the database. The encrypted password can be seen by everyone. The user sends the clear pass- word in the same mail as the request to change an object. It is difficult to get the original, clear password from the encrypted one; that is why the encrypted one can be put in the public database. However, passwords based on words which may be found in a dictionary should be avoided; encrypted pass- words based on such words may be broken by the use of lots of fast machines running for a sufficiently long time. This scheme uses the Unix crypt(3) routine, which is also used for login passwords under Unix. This routine provides a so called "trap door" function, the inverse of which is somewhat hard to calculate. The password provided by the user is encrypted with this function and stored in its encrypted form only. When the user later provides the password again for authentication, the encryption is repeated and the results are compared. Since the original (cleart- ext) password cannot easily be computed from the encrypted version the encrypted password does not have to be kept secret. The is the encrypted password. This can either be obtained locally with the appropri- ate Unix tools or on e-mail request from . When sending in update requests the cleartext password has to be provided in the message body by specifying password: cleartext-password at the beginning of a line and preceding any update requests to be thus authenticated. The pass- word will remain valid for all requests following it in the same e-mail message or until another ____________________________________________________ ripe-157.txt Page 63 ripe-157 A. M. R. Magee ____________________________________________________ password is specified. This scheme is slightly stronger than the MAIL-FROM scheme. It is by no means meant to keep out a determined malicious attacker. The crypt function is vulnerable to exhaustive search by (lots of) fast machines and programs to do the searching are widely available. For this reason it is strongly discour- aged to use encrypted passwords also used for other purposes such as Unix login accounts in this scheme. As you are publishing the encrypted password in the database it is open to attack. The usual caveats about crypt passwords apply, so is not very wise to use words or combinations nations of words found in any dictionary of any language. See [R. Morris, K. Thompson: Password Security: A Case History] for more details about the scheme and its vulnerabilities. Example of use: * auth: NONE * auth: CRYPT-PW dhjsdfhruewf * auth: MAIL-FROM .*@ripe.net The "auth" field must be included in a mntner object, even if no authorisation scheme other than `NONE' is required. Furthermore, several "auth"fields may be included in the same mntner object. Example: mntner: AMRM1-RIPE-MNT descr: Ambrose's mntner object. admin-c: AMRM1-RIPE tech-c: AMRM1-RIPE upd-to: ambrose@ripe.net mnt-nfy: ambrose@ripe.net auth: MAIL-FROM Ambrose.Magee@ripe.net auth: MAIL-FROM ripe-dbm@ripe.net auth: CRYPT-PW eiktegisvfxg notify: ambrose@ripe.net mnt-by: AMRM1-RIPE-MNT changed: ambrose@ripe.net 961011 source: RIPE ____________________________________________________ ripe-157.txt Page 64 ripe-157 A. M. R. Magee ____________________________________________________ Multiple authentication methods can be specified in the same mntner object. They all have equal status i.e. any one of the authenticators is sufficient to authenticate the update request from the main- tainer. In the above example, objects protected by this mnt- ner object may be changed if: * (1) the e-mail message is from Ambrose.Magee@ripe.net; * (2) the e-mail message is from ripe- dbm@ripe.net; * (3) the e-mail message contains the unencrypted form of the password eiktegisvfxg. If multiple maintainers maintain an object this feature should not be used. Multiple maintainers should be represented by multiple mntner objects referenced in the mnt-by attribute. There is no way in the current model to require a combination of multiple authenticators to authenticate a request. 2.3.4 Obtaining a mntner object: Unlike other objects, mntner objects are not created automatically; they are created on your behalf by the staff at RIPE NCC. To obtain a mntner object, do the following: (i) First, obtain a template of a mntner object by using the "-t" option with the `whois' command (see Section 2.1). (ii) Fill in the template and send it to , from where it will be forwarded to . You may also send it directly to . (iii) Your mntner object will be created as soon as possible, if your request satisfies the criteria mentioned below. Criteria (i) The request comes from someone who is responsi- ble for the maintenance of objects that are related ____________________________________________________ ripe-157.txt Page 65 ripe-157 A. M. R. Magee ____________________________________________________ to public address space, domain names and routes. (ii) Normally, individuals who request a mntner object already have objects in the RIPE database which they wish to protect. (iii) Such objects should be related to public address space or domain names that have been assigned by the appropriate registry. ____________________________________________________ ripe-157.txt Page 66 ripe-157 A. M. R. Magee ____________________________________________________ 2.4 Hierarchical Object Protection You can protect against people *creating* (only cre- ating) objects directly (one level) below in the hierarchy of an object type (only for "inetnum" or "domain" objects) by using your maintainer in a "mnt-lower:" attribute. The authorization method of this maintainer object will then be used upon cre- ation of any object directly below the object that contains the "mnt-lower:" attribute. Inetnum objects As an example, suppose that these four allocations of IP address space exist: 10.0.0.0/8 CCC (Citrus Co-ordination Centre) 10.0.0.0/16 Orange Registry 10.4.0.0/16 Grapefruit Registry 10.6.128.0/19 Lemon Registry The details of these allocations are shown below: inetnum: 10.0.0.0 - 10.255.255.255 netname: CITRUS-RR descr: CITRUS CC descr: Citrus Coordination Center country: NL admin-c: RN1-RIPE tech-c: CO19-RIPE status: ALLOCATED UNSPECIFIED mnt-by: SINAS-MNT mnt-lower: SINAS-MNT changed: orange@ripe.net 960921 changed: orange@ripe.net 960922 source: TEST ____________________________________________________ ripe-157.txt Page 67 ripe-157 A. M. R. Magee ____________________________________________________ inetnum: 10.0.0.0 - 10.0.255.255 netname: ORANGE-REG descr: Orange Registry country: NL admin-c: CO19-RIPE tech-c: CO19-RIPE status: ALLOCATED PA mnt-by: SINAS-MNT mnt-lower: SINAS-MNT changed: orange@ripe.net 960921 source: TEST inetnum: 10.4.0.0 - 10.4.255.255 netname: GRAPEFRUIT-REG descr: Grapefruit Registry country: NL admin-c: CO19-RIPE tech-c: CO19-RIPE status: ALLOCATED PA mnt-by: SINAS-MNT changed: orange@ripe.net 960921 source: TEST inetnum: 10.6.128.0 - 10.6.159.255 netname: LEMON-REG descr: The Lemon Registry country: NL admin-c: CO19-RIPE tech-c: CO19-RIPE status: ALLOCATED PA mnt-by: CITROEN-MNT mnt-lower: CITROEN-MNT changed: orange@ripe.net 960921 source: TEST There are two mntner objects used in "mnt-lwr" attributes: SINAS-MNT and CITROEN-MNT. The details of these are: ____________________________________________________ ripe-157.txt Page 68 ripe-157 A. M. R. Magee ____________________________________________________ mntner: SINAS-MNT descr: Fruit Maintainer admin-c: RN1-RIPE tech-c: CO19-RIPE upd-to: orange@ripe.net mnt-nfy: orange@ripe.net auth: CRYPT-PW jdOQ2EKS1k6cc remarks: passwd is "sinas" mnt-by: SINAS-MNT changed: orange@ripe.net 960920 source: TEST mntner: CITROEN-MNT descr: Lemon Registry Maintainer admin-c: CO19-RIPE tech-c: CO19-RIPE upd-to: orange@ripe.net mnt-nfy: orange@ripe.net auth: NONE mnt-by: CITROEN-MNT changed: orange@ripe.net 960922 source: TEST A summary of the IP address allocation objects and their mnt-lwr attributes is shown below: +------------------------------------------------------+ | Authorisation Examples | +--------------+---------------+-----------------------+ |Address Space | Mnt-Lwr | Authentication Method | +--------------+---------------+-----------------------+ |10.0.0.0/8 | SINAS-MNT | CRYPT-PW | |10.0.0.0/16 | SINAS-MNT | CRYPT-PW | |10.4.0.0/16 | Not specified | | |10.6.128.0/19 | CITROEN-MNT | NONE | +--------------+---------------+-----------------------+ Example 1: Suppose that someone tries to add this allocation: ____________________________________________________ ripe-157.txt Page 69 ripe-157 A. M. R. Magee ____________________________________________________ inetnum: 10.3.0.0 - 10.3.255.255 netname: LIME-REG descr: Lime Registry country: NL admin-c: CO19-RIPE tech-c: CO19-RIPE status: ALLOCATED PA changed: orange@ripe.net 960921 source: TEST This attempt to add an object fails. The IP address range, 10.3.0.0 - 10.3.255.255, is one level below CITRUS-RR, i.e. 10.0.0.0 - 10.255.255.255. Because CITRUS-RR has SINAS-MNT in its mnt-lwr attribute and because SINAS-MNT has a CRYPT-PW as its authentication scheme, this update fails. Example 2: An attempt is made to add this assignment: inetnum: 10.3.255.0 - 10.3.255.255 netname: LIME-NET descr: Lime Inc. country: NL admin-c: CO19-RIPE tech-c: CO19-RIPE status: ASSIGNED PA changed: orange@ripe.net 960921 source: TEST This object is directly below the CITRUS-RR object; i.e. it is one level below 10.0.0.0 - 10.255.255.255. For the same reason as in Example 1, this update fails. Example 3: An attempt is made to add this assignment: ____________________________________________________ ripe-157.txt Page 70 ripe-157 A. M. R. Magee ____________________________________________________ inetnum: 10.0.255.0 -10.0.255.255 netname: ROTTEN-NET descr: Rotten Fruit Inc. country: NL admin-c: CO19-RIPE tech-c: CO19-RIPE status: ASSIGNED PA changed: orange@ripe.net 960921 source: TEST There is an object directly one level above this, i.e. 10.0.0.0 - 10.0.255.255 (the Orange Registry). The Orange Registry object has a mnt-lwr, namely SINAS-MNT. SINAS-MNT uses a crypted password as an authentication method. Thus, this update fails. Example 4 An attempt is made to add this assignment: inetnum: 10.4.128.0 - 10.4.128.127 netname: SQUISHY-NET descr: Squishy Grapefruit country: NL admin-c: CO19-RIPE tech-c: CO19-RIPE status: ASSIGNED PA changed: orange@ripe.net 960921 source: TEST 10.4.128.0 - 10.4.128.127 is directly below the inetnum object 10.4.0.0 - 10.4.255.255 (the Grape- fruit Registry); thus, the inetnum object, 10.4.128.0 - 10.4.128.127 is created. Furthermore, no notification message is generated and there is no way of knowing who is authorised to create inetnum objects under 10.4.0.0 - 10.4.255.255. Example 5 An attempt is made to add this assignment: ____________________________________________________ ripe-157.txt Page 71 ripe-157 A. M. R. Magee ____________________________________________________ inetnum: 10.6.128.0 - 10.6.128.127 netname: BITTER-NET descr: Bitter Lemon country: NL admin-c: CO19-RIPE tech-c: CO19-RIPE status: ASSIGNED PA changed: orange@ripe.net 960921 source: TEST 10.6.128.0 - 10.6.128.127 is directly below the inetnum object 10.6.128.0 - 10.6.159.255 (the LEMON- REG), which has CITROEN-MNT as its mnt-lwr. CIT- ROEN-MNT uses the authentication method NONE; thus the inetnum object 10.6.128.0 - 10.6.128.127 is cre- ated. However, unlike Example 4, someone is noti- fied that the object was created. Summary When a new inetnum object is sent into the RIPE Database, only the next (existing) level above the new object is checked for the presence of a mnt-lwr attribute. Higher, existing levels are not checked. ____________________________________________________ ripe-157.txt Page 72 ripe-157 A. M. R. Magee ____________________________________________________ 2.5 Mirroring the RIPE Database. This section contains four parts: * Setting up a secondary * Static secondaries * "Near Real-Time" Mirrors * Likely Problems Setting up a secondary There are five steps: 1. Get the software: ftp://ftp.ripe.net/ripe/dbase/software 2. Configure and install the software: Unpack using g(un)zip and tar Follow instructions in ./INSTALL: * Modify ./etc/ripedb.config * make; make install 3. Follow the instructions in ./SECONDARIES * The following variables should be set in ./etc/ripedb.config: DBFILE RIPE /home/dbase/data/ripe.db DBFILE RIPE /home/dbase/data/ripe.db SPLIT * Get the data file: ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz Split data files are available from: ftp.ripe.net/ripe/dbase/data/ripe.db.??.gz 4. Unpack the data and index it: You must index each of the split database files. ____________________________________________________ ripe-157.txt Page 73 ripe-157 A. M. R. Magee ____________________________________________________ For a non -SPLIT RIPE database, you must only index one file (the non-split database file). See the instructions in ./SECONDARIES. 5. Start whoisd ./bin/whoisd -D Static Secondaries You can repeat the above procedure every day, week or month. The procedure is too long to do every hour. "Near Real-Time Mirrors" You must be on the Access List; send the IP number of your machine to . Use the syncdb command to update your database. Example: syncdb -h whois.ripe.net -s RIPE -u 68400:600 where -h = host => where to mirror from -s = source => the source database -u duration:interval (both in seconds) duration: how long to run syncdb interval: how often to do updates You should choose a minimum interval of 10 minutes. Advice Every update creates a file => remove the update files regularly. ____________________________________________________ ripe-157.txt Page 74 ripe-157 A. M. R. Magee ____________________________________________________ Do a full resynchronisation * every week * every month Start indexing only after the indexing is complete. Before rebooting the secondary: * Disable running cron jobs. * Let running jobs die or complete Set up an account to take mail from your cron job program. Remember to look at it. Possible problems Performance becomes slow. Too many update files. Database is not consistent. This can happen as a consequence of your server crashing. Mutiple real-time mirror processes. The time inter- val in the cronjob is too short (< 10 minutes). ____________________________________________________ ripe-157.txt Page 75 ripe-157 A. M. R. Magee ____________________________________________________ Appendix A Attributes The lay-out of this appendix is: address Full postal address of a person. Free Text. admin-c An on-site contact (person) advisory Advises a specific `target' autonomous system (AS) to use the information that is defined in this attribute. as-exclude ____________________________________________________ ripe-157.txt Page 76 ripe-157 A. M. R. Magee ____________________________________________________ A list of transit ASes from which all routes will be ignored. exclude to as-in Description of policy for route acceptance. from accept as-list The list of ASes or other AS macros that make up an AS Macro. ... as-macro The identifier of a macro containing at least two Autonomous Systems. AS- where consists of uppercase leters only. as-name A descriptive name associated with an AS. Uppercase letters, dashes ("-") and digits, no spaces. Must start with a letter. ____________________________________________________ ripe-157.txt Page 77 ripe-157 A. M. R. Magee ____________________________________________________ as-out Description of policy for route announcement. to announce as-transit The transit preferences of an AS. transit to aut-num The autonomous system number. This must be a uniquely allocated autonomous system number from an AS registry (e.g.RIPE NCC, the Inter-NIC, etc). "AS" aut-sys This attribute is OBSOLETE. auth Scheme to be used to authenticate update requests. author ____________________________________________________ ripe-157.txt Page 78 ripe-157 A. M. R. Magee ____________________________________________________ Limerick author. authority The formal authority for a community. This could be an organisation, institute, committee, etc. Free text (alphanumeric characters, ".", "-", " bdry-gw This attribute is OBSOLETE. bdrygw-l List of boundary gateways. Obsolete in the inetnum object. bis This is the `boundary intermediate system' attribute. or changed Who previously changed this object and when this change was made. ____________________________________________________ ripe-157.txt Page 79 ripe-157 A. M. R. Magee ____________________________________________________ E-mail address of person updating the object. DATE in YYYYMMDD or YYMMDD format. comm-list A list or 1 or more communities of which a route is part. ... community Name of a community. Uppercase text which cannot start with a routing policy expression keyword. connect This attribute is OBSOLETE country Name of the country of the admin-c. 2 letter uppercase ISO 3166 country code. default There are two uses of this attribute; (a) with the dom-prefix (CLNS) object; (b) with the aut-num (AS) object: ____________________________________________________ ripe-157.txt Page 80 ripe-157 A. M. R. Magee ____________________________________________________ is optional. descr A short description of this object. All characters possible. dom-in dom-in dom-name The IP domain name for a ConnectionLess Network Ser- vice object. Fully qualified domain name without trailing "." dom-net List of IP networks in a domain. Dotted quad including trailing 0's. dom-out dom-out attribute ____________________________________________________ ripe-157.txt Page 81 ripe-157 A. M. R. Magee ____________________________________________________ dom-prefix dom-prefix domain IP domain name. Full qualified domain name without trailing ".". e-mail The e-mail address of a person or role. RFC-822 address. fax-no The fax number of a person or role + gateway This attributre is OBSOLETED ____________________________________________________ ripe-157.txt Page 82 ripe-157 A. M. R. Magee ____________________________________________________ guardian This attribute functions as a "notify" attribute. RFC-822 address. hole Indicates the parts of the address space covered to which the originator does not provide connectivity. Classless prefix length representation. / ias-int OBSOLOETED NONE ifaddr An interface address within an internet router. inet-rtr Fully qualified domain name of an internet router. Fully qualified domain name without trailing "." ____________________________________________________ ripe-157.txt Page 83 ripe-157 A. M. R. Magee ____________________________________________________ inet6num Full IP version 6 address. / inetnum A range of IP address space. x.x.x.x - x.x.x.x, where 0 =< x =< 255 interas-in Incoming local preferences on an inter-AS connec- tion. from accept interas-out Outgoing local preferences on an inter-AS connec- tion. to [] announce is optional and is defined as: (=) limerick Title of a limerick. LIM-, where string can include alphanumeric characters, "-" character. ____________________________________________________ ripe-157.txt Page 84 ripe-157 A. M. R. Magee ____________________________________________________ localas The autonomous system in which a router belongs. AS. location This attribute is OBSOLETE maintainer This attribute is OBSOLETE. mnt-by The identifier of a registered mntner object used for authorization and authentication. mnt-lower The identifier of a registered mntner object used for hierarchical authorization and authentication. mnt-nfy The e-mail address to be notified when an object protected by a mntner is successfully updated. ____________________________________________________ ripe-157.txt Page 85 ripe-157 A. M. R. Magee ____________________________________________________ RFC-822 address. mntner The name of a mntner object. Must be an unique mnt- ner name, but can be identical to AS names, nic-han- dles. netname The name of a range of IP address space. nic-hdl The NIC handle of a role or person object. This can be a RIPE NIC-handle or a NIC-handle assigned by other regional registries. RIPE NIC-handle: <0-999>-RIPE notify The e-mail address to which notifications of changes to an object should be sent. nserver ____________________________________________________ ripe-157.txt Page 86 ripe-157 A. M. R. Magee ____________________________________________________ List of nameservers for a domain object; a minimum of two is mandatory . OR nsf-in This attribute is OBSOLETE nsf-out This attribute is not used. Obsolete op-fax Fax Number + Optional: spaces may be used to split up the number into its constituent components. "." characters can also be used to separate the digits. op-mail E-mail address of a person or role object op-phone ____________________________________________________ ripe-157.txt Page 87 ripe-157 A. M. R. Magee ____________________________________________________ Telephone number + + Optional: spaces may be used to split up the number into its constituent components. "." characters can also be used to separate the digits. origin The autonomous system announcing a route. AS peer Details of any (interior or exterior) router peer- ings. [Local AS] [Local AS] is optional. person The full name of an adminstrative, technical or zone contact person specified in another object. Do not use titles such as "Dr.", "Prof.", "Mv.", "Ms.", "Mr.", etc. where each name is composed of alphabetic characters. phone Telephone number ____________________________________________________ ripe-157.txt Page 88 ripe-157 A. M. R. Magee ____________________________________________________ + + ext. Optional: spaces may be used to split up the phone number into its constituent components. "." charac- ters can also be used between to separate the dig- its. remarks General remarks. Can include an URL or RFC822 address (if preceeded by mailto:). rev-srv Domain name server for a range of IP addresses. Fully qualified name without trailing "." role The full name of a role entity e.g. RIPE DBM. Two components, each consisting of alphabetic char- acters. Note: there is no "-" character between the two components of the the name. rout-pr Routing privilages attribute. Uppercase letters, digits or "-" characters. ____________________________________________________ ripe-157.txt Page 89 ripe-157 A. M. R. Magee ____________________________________________________ route A route being anounced. Classless prefix length representation. / routpr-l This attribute is OBSOLETE source Identifier of the database containing authoritative data for this object. Use RIPE for objects in the RIPE Database. Uppercase Text. status Type of allocated or assigned address space. Uppercase Text. sub-dom List of the sub-domains of a domain tech-c ____________________________________________________ ripe-157.txt Page 90 ripe-157 A. M. R. Magee ____________________________________________________ A technical contact. text Must be humourous, but not malicious or insulting. :-) Free Text. trouble Information on who to contact when there are prob- lems. upd-to The e-mail address to be notified when an object protected by a mntner is unsuccessfully updated. RFC-822 address withdrawn Indicates who withdrew a route and the date. E-mail address of person withdrawing the route. DATE in YYYYMMDD or YYMMDD format. ____________________________________________________ ripe-157.txt Page 91 ripe-157 A. M. R. Magee ____________________________________________________ zone-c NIC-handle of the person with authority over a zone. ____________________________________________________ ripe-157.txt Page 92 ripe-157 A. M. R. Magee ____________________________________________________ Appendix B Objects The lay-out of this appendix is: as-macro An `AS Macro' is a group of autonomous systems with the same routing policies. See ripe-181 for details. aut-num The aut-num object describes the details of the reg- istered owner of an Autonomous System and their routing policy for that AS. See ripe-181 and RFC- BGP4 for details. boundary-gateway This object is obsolete. community A community is a group of routes that cannot be rep- resented by an AS or group of AS's. See ripe-181 for details. dom-prefix The dom-prefix object represents CLNS address space and routing. domain ____________________________________________________ ripe-157.txt Page 93 ripe-157 A. M. R. Magee ____________________________________________________ A domain object represents a Top Level Domain (TLD) or other domain registrations. It is for information only. inet-rtr The inet-rtr object represents an internet router within a routing registry. See ripe-122 for details. inet6num An experimental object for IP Version 6 addresses. inetnum An inetnum object contains information on alloca- tions and assignments of IP address space. See ripe-142 for information on requesting IP address space. limerick The limerick object represents a humourous poem which has five lines and the rhyme scheme "aabba". mntner The mntner object contains details of who is autho- rised to make changes to RIPE Database objects and details of a process that actually verifies that the person who makes the changes is authorised to do so. Mntner objects are not created automatically, but are forwarded to RIPE NCC staff for manual creation. person The person object contains information on how to contact those people who are responsible for network operations or RIPE Database objects. ____________________________________________________ ripe-157.txt Page 94 ripe-157 A. M. R. Magee ____________________________________________________ role The role object represents a "help desk", a network operations centre or a contact point for help or information on network operations. route The route object represents a single route injected into the Internet routing mesh. routing privileges This object is obsoleted ____________________________________________________ ripe-157.txt Page 95 ripe-157 A. M. R. Magee ____________________________________________________ Appendix Mailing Lists 1. Introduction There are three mailing lists that are relevant to the use and development of the RIPE database: * db-wg * db-beta * rr-impl 1.1. db-wg This is the mailing list of the RIPE Database Work- ing Group. This working group deals with all aspects of the RIPE network management database. The current chair of this group is Wilfried Woeber . Membership of this list is open. The list is archived since October 1992. Send mail to . 1.2. rr-impl This mailing list is to discuss Routing Registry Implementations. Membership is open, but aimed at Routing Registry Implementors. ____________________________________________________ ripe-157.txt Page 96 ripe-157 A. M. R. Magee ____________________________________________________ The list is archived since Feb 1994 Send mail to . 1.3. info db-beta This mailing list is used to exchange information about the current beta release of the RIPE database software. The list membership is closed to beta testers. The list is archived since October 1993. Send mail to . 2. More Information For more information about any of these lists, con- tact or . ____________________________________________________ ripe-157.txt Page 97