Your IP address is 54.237.235.12

Filters

Appendice for reference manual

TABLE OF CONTENT

      A1. Object attributes
A2. AFRINIC Database response codes and messages
A2.1 Query errors
A2.2 Access errors
A2.3 Connection errors
A2.4 NRTM errors
A2.5 Referral text
A3. Copyright information
A3.1 AFRINIC Database Copyright
A3.2 A3.2 RFC Copyright Statement Acknowledgements
References

A1. Object attributes

Shown below are the syntax definitions of the object attributes supported by the AFRINIC Database. The value of an attribute has a type. Some of the most commonly used types are shown in Table A1. Others are explained in the descriptions of the attributes.

Table A1. Commonly used attribute types

 

 

Descriptions of the attributes are listed below in the following format:

 

address:
Full postal address of a contact.

admin-c:
References an on-site administrative contact.

aggr-bndry:
Defines a set of ASes, which form the aggregation boundary.

aggr-mtd: inbound | outbound []
Specifies how the aggregate is generated. Please see [1] for more information.

alias:
Specifies a canonical DNS name for the router.

as-block: -
Specifies the range of ASNs that the as-block object represents.
Please see [2] for more information.

as-name:
A descriptive name associated with an AS.

as-set:
Defines the name of the set.

auth:
Defines an authentication scheme to be used.
and can take the following values:



Description:

NONE

No authentication is required to make changes to the object protected with such authentication scheme.

MAIL-FROM

Regular expression that matches e-mail addresses. This authentication method checks the content of the RFC 822 "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 successfully. The regular expressions supported are described in POSIX 1003.2 section 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 content of the "From:" header including comments if present. No attempt is made to isolate the mailbox part.

This authentication scheme is very weak. Forging RFC 822 headers does not take much effort or ingenuity. The reason for the scheme's existence is that it easily prevents accidental updates rather than allowing them first and fixing them later when notified.

CRYPT-PW

encrypted password, produced by UNIX crypt(3) routine

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 discouraged 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 it is no very wise to use words or combinations of words found in any dictionary of any language.

PGPKEY-

Strong scheme of authentication. is the PGP key ID to be used for authentication. This string is the same one that is used in the corresponding key-cert object's "key-cert:" attribute.

author:
References a limerick author.

aut-num:
The autonomous system number.

certif:
Contains the public key. The value of the public key should be supplied either using multiple "certif:" attributes, or in one "certif:" attribute. In the first case, this is easily done by exporting the key from your local key ring in ASCII armored format and prepending each line of the key with the string "certif:". In the second case, line continuation should be used to represent an ASCII armored format of the key. All the lines of the exported key must be included; also the begin and end markers and the empty line which separates the header from the key body.

changed: []
Specifies who submitted the update, and when the object was updated.
The format of the date is YYYYMMDD; dates in the future are not allowed. If the date is not specified, the database will put the date when the update was actually processed.

components: [ATOMIC] [[] [protocol ...]]
The "components:" attribute defines what component routes are used to form the aggregate. is a routing protocol name such as BGP4, OSPF or RIP and is a policy expression. Please refer to RFC 2622 [1] for more information.

country:
Identifies the country. must be a valid two-letter ISO 3166 country code.

cross-mnt: list of
references mntner(s) to be notified. The "cross-mnt:" attribute may be used in:

* route object - to get a notification for any overlaps with the prefix specified in that route object;

* aut-num object - to get a notification for overlaps with any of the prefixes announced in route objects in which the given AS number is specified in the "origin:" attribute.

A notification will be sent to mailbox(es) listed in cross-nfy and mailbox(Es) listed in the "mnt-nfy:" attributes of the maintainers referenced by the cross-mnt whenever an overlapping route is added or removed.

cross-nfy:
The cross-nfy attribute contains a NIC-handle pointing to a person or role object, the email address of which will be used for notification about the addition or removal of route objects, which overlap the prefixes of the already registered route objects. The "cross-nfy:" attributes may be used in:

* route object - to get a notification for any overlaps with the prefix specified in that route object;

* aut-num object - to get a notification for overlaps with any of the prefixes announced in route objects in which the given AS number is specified in the "origin:" attribute. See also "cross-mnt:" attribute.

default: to [action ] [networks ]
Specifies default routing policies. Please refer to RFC 2622 [1] for more information.

descr:
A short description related to the object

domain:
DNS name. is a fully qualified domain name without trailing ".".

dom-net: AFRINIC-list of
List of IP networks in a domain.

e-mail:
Specifies an e-mail address of a person or role.

encryption: PGPKEY-
References a key-cert object representing a CSIRT public key used to encrypt correspondence sent to the CSIRT. is the D of the PGP public key in 8-digit hexadecimal format without "0x" prefix.

export: to [action ] . . . to [action ] announce
Specifies an export policy expression. Please refer to RFC 2622 for more information.

export-comps:
Specifies an RPSL filter that matches the more specifics that need to be exported outside the aggregation boundary. Please refer to RFC 2622 [1] for more information.

fax-no:
The fax number of a contact.

filter:
Defines the set's policy filter, a logical expression which when applied to a set of routes returns a subset of these routes. Please refer to RFC 2622 [1] for more information.

filter-set:
Defines the name of the filter. Please refer to RFC 2622 [1] for more information.

fingerpr:
A fingerprint of a key certificate generated by the database. Please refer to RFC 2726 [9] for detailed description of this attribute.

holes: list of
Lists the component address prefixes that are not reachable through the aggregate route (perhaps that part of the address space is unallocated). Please refer to RFC 2622 [1] for more information.

ifaddr: masklen [action ]
Specifies an interface address within an Internet router. Please refer to RFC 2622 [1] for more information.

import: [protocol ] [into ] from [action ]. . .from [action ] accept
Specifies import policy expression. Please refer to RFC 2622 [1] for more information.

inetnum: -
Specifies a range of IPv4 that inetnum object presents. The ending address should be greater than the starting one.

inet6num: /
Specifies a range of IPv6 addresses in prefix notation. The is an integer in the range from 0 to 128.

inet-rtr:
Fully qualified DNS name of the inet-rtr without trailing ".". Please refer to RFC 2622 [1] for more information.

inject: [at ] [action ] [upon ]
Specifies which routers perform the aggregation and when they perform it. Please refer to RFC 2622 [1] for more information.

irt:
A unique identifier of an irt object. The name should start with the prefix "IRT-", reserved for this type of object.

irt-nfy:
Specifies the e-mail address to be notified when a reference to the irt object is added or removed.

key-cert: PGPKEY-
Defines the public key stored in the database. is the ID of the PGP public key in 8-digit hexadecimal format without "0x" prefix.

local-as:
Specifies the autonomous system that operates the router. Please refer to RFC 2622 [1] for more information.

limerick: LIM-
Specifies the title of the limerick. can include alphanumeric characters, "-" character.

method:
Defines the type of the public key. Currently the only method that is supported is "PGP". Please refer to RFC 2726 [9] for detailed description of this attribute.

member-of: list of
This attribute can be used in the route, aut-num and inet-rtr classes. The value of the "member-of:" attribute identifies a set object that this object wants to be a member of. This claim, however, should be acknowledged by a respective "mbrs-by-ref:" attribute in the referenced object. Please refer to RFC 2622 [1] for more information.

members: list of or
or members: list of
or
or
members: list of or or
Lists the members of the set. The first form appears in the

as-set object. The syntax of is the same as the syntax of . The second form appears in the route-set object. The syntax of is the same as the syntax of . The third form appears in the rtr-set object. The syntax of is the same as the syntax of . Please refer to RFC-2622 [1] for more information.

mbrs-by-ref: list of | ANY
This attribute can be used in all "set" objects; it allows indirect population of a set. If this attribute is used, the set also includes objects of the corresponding type (aut-num objects for as-set, for example) that are protected by one of these maintainers and whose "member-of:" attributes refer to the name of the set. If the value of a "mbrs-by-ref:" attribute is ANY, any object of the corresponding type referring to the set is a member of the set. If the "mbrs-by-ref:" attribute is missing, the set is defined explicitly by the "members:" attribute.

mntner:
A unique identifier of the mntner object.

mnt-by: list of
Specifies the identifier of a registered mntner object used for authorisation of operations performed with the object that contains this attribute.

mnt-irt: list of
May appear in an inetnum or inet6num object. It points to an existing irt object representing CSIRT that handles security incidents for the address space specified by the inetnum or inet6num object.

mnt-lower: list of
Specifies the identifier of a registered mntner object used for hierarchical authorisation. Protects creation of objects directly (one level) below in the hierarchy of an object type (only for inetnum, inet6num, as-block, aut-num, route or domain objects). The authentication method of this maintainer object will then be used upon creation of any object directly below the object that contains the "mnt-lower:" attribute.

mnt-nfy:
Specifies the e-mail address to be notified when an object protected by a mntner is successfully updated.

mnt-routes: [ { list of } | ANY ]
May appear in an aut-num, inetnum or route object. This attribute references a maintainer object which is used in determining authorisation for the creation of route objects. After the reference to the maintainer, an optional list of prefix ranges inside of curly braces or the keyword "ANY" may follow. The default, when no additional set items are specified, is "ANY" or all more specifics. Please refer to RFC-2622 [1] for more information.

netname:
Specifies the name of a range of IP address space. The syntax of the attribute is the same as the syntax of the attribute, but it does not have a restriction on RPSL reserved prefixes.

nic-hdl:
Specifies the NIC handle of a role or person object. When creating an object, one can also specify an "AUTO" NIC handle by setting the value of the attribute to "AUTO-1" or AUTO-1. In such case the database will assign the NIC handle automatically.

notify:
Specifies the e-mail address to which notifications of changes to an object should be sent.

nserver: AFRINIC-list of ( | )
Specifies the nameservers of the domain.

origin:
Specifies the AS that originates the route. The corresponding aut-num object should be registered in the database.

owner:
Specifies the owner of the public key. Please refer to RFC 2726 [9] for detailed description of this attribute.

peer:




May appear in an inet-rtr object. Specifies a protocol peering with another router. Please refer to RFC 2622 [1] for more information.

peering:
Defines a peering that can be used for importing or exporting routes. Please refer to RFC 2622 [1] for more information.

peering-set:
Specifies the name of the peering-set. Please refer to RFC 2622 [1] for more information.

person:
Specifies the full name of an administrative, technical or zone contact person for other objects in the database. cannot contain titles such as "Dr.", "Prof.", "MV", "Ms.", "Mr.", etc. It is composed of alphabetic characters.

peering-set:
Specifies the name of the peering-set. Please refer to RFC 2622 [1] for more information.

phone:
Specifies a telephone number of the contact.

refer: []
Specifies the referral type, hostname and port that the server should use to redirect the query when using referral mechanism for lookups for domain objects. Please see section 2.7 "Referral mechanism for domains" for more information.
specifies the type of referral to be used. Please see the table below for the supported types.
is the DNS name or of the referred host.
is an integer specifying TCP port number at which queries are accepted by the referred host. If is omitted, the default number of 43 is used.

Referral type Description

SIMPLE

Only lookup key (domain name) is passed to the referred server. All query flags are stripped.

INTERNIC

Same as SIMPLE. Supported for backward compatibility.

AFRINIC

Used when the referred server understands AFRINIC query flags. With this type of referral, all query flags specified by the client will be passed to the referred server unmodified.

CLIENTADDRESS

Same as SIMPLE, but the server will add "-V," flag to the query, whereis the version number of the server andis the IP address of the client that made this query. This referral type allows the referred host to perform accounting and implement an access control for clients using the AFRINIC Database server as a proxy.

referral-by:
This attribute is required in the mntnr object. It may never be altered after the addition of the maintainer. This attribute refers to the maintainer that created this maintainer. Currently, all mntner objects are created manually by the Database Administration, so the value of the "referral-by:" attribute should be "AFRINIC-DBM-MNT"

remarks:
Contains remarks.

role:
Specifies the full name of a role entity, e.g. AFRINIC DBM.

rev-srv: AFRINIC-list of
Specifies a DNS nameserver for a range of IP addresses represented by the inetnum object that contains this attribute.

route:
Specifies the prefix of the interAS route. Together with the "origin:" attribute, constitutes a primary key of the route object.

route-set:
Specifies the name of the route set. It is a primary key for the route-set object. Please refer to RFC 2622 [1] for more information.

rtr-set:
Defines the name of the rtr-set. Please refer to RFC 2622 [1] for more information.

signature: PGPKEY-
References a key-cert object representing a CSIRT public key used by the team to sign their correspondence. is the ID of the PGP public key in 8-digit hexadecimal format without "0x" prefix.

source:
Specifies the registry where the object is registered. Should be "AFRINIC" for the AFRINIC Database.

status:
Specifies the status of the address range represented by inetnum or inet6num object. For an inetnum object can have one of these values:

* ALLOCATED PA
* ALLOCATED PI
* ALLOCATED UNSPECIFIED
* ASSIGNED PA
* ASSIGNED PI
* LIR-PARTITIONED PA
* LIR-PARTITIONED PI
* SUB- ALLOCATED PA

Please refer to the AFRINIC document "IPv4 Address Allocation and Assignment Policies in the AFRINIC Service Region" for further information. Please refer to [10] regarding usage of the LIR-PARTITIONED status value.

For inet6num,can have one of the following values:

* ALLOCATED-BY-RIR - For allocations made by an RIR to an LIR.
* ALLOCATED-BY-LIR - For allocations made by an LIR or an LIR's

downstream customer to another downstream organisation.

* ASSIGNED - For assignments made to End User sites.

Please refer to [13] regarding usage of the status value for inet6num objects.

sub-dom: AFRINIC-list of
Specifies list of sub-domains of a domain. Domain names are relative to the domain represented by the domain object that contains this attribute.

tech-c:
References a technical contact.

text:
Contains text of the limerick. Must be humorous, but not malicious or insulting.

trouble:
Contains information on who to contact when there are problems.

upd-to:
Specifies the e-mail address to be notified when an object protected by a mntner is unsuccessfully updated. See also section 2.5.2. "Notifications".

zone-c:
References a zone contact.

A2. AFRINIC Database response codes and messages

If the server encounters a problem, an error message is returned as

a query result. The format of an error message is as follows:

%ERROR:#:,

where # is the error code andis a short description of the problem, possibly followed by a more descriptive message, each line of which starts with % followed by a white space and a text.

Example:

A2.1 Query errors

%ERROR:101: no entries found
No entries were found in the selected source(s).

%ERROR:102: unknown source
Unknown source is requested (-s flag). Use -q sources for a list of available sources.

%ERROR:103: unknown object type
Unknown object type is specified in the filter expression (-T flag)

%ERROR:104: unknown attribute
Unknown attribute is specified in the inverse query (-i flag). See section 1.0 "Queries in the AFRINIC Database" for more information.

%ERROR:105: attribute is not searchable
The attribute specified in the inverse query is not searchable (-i flag). See section 1.0 "Queries in the AFRINIC Database" for more information.

%ERROR:106:
no search key specified No search key has been specified in the query.

A2.2 Access errors

Access from the host has been permanently denied because of excessive querying. You need to contact Database Administration; ( This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) to discuss this problem.

%ERROR:202: access control limit reached
Limit of returned objects has been reached. The connection is terminated. Continued attempts to excessively query the database will result in permanent denial of service. See section 2.8 "Access control for queries" for more information.

%ERROR:203: address passing not allowed
The host is not registered as a proxy, thus it is not allowed to pass addresses on the query line ("-V" flag). See section 2.8 "Access control for queries" for more information.

%ERROR:204: maximum referral lines exceeded
The referral query result exceeded maximum number of lines. Only maximum lines are output and connection is closed by the server.

A2.3 Connection errors

%ERROR:301: connection has been closed
The connection is administratively closed.

%ERROR:302: referral timeout
The connection was closed due to referral timeout.

%ERROR:303: no referral host
Referral host cannot be found.

%ERROR:304: referral host not responding
The connection to the referral host cannot be established.


A2.4 NRTM errors

%ERROR:401: invalid range: Not within -
This happens when the requested range or part of it is outside the serial numbers available at the server. is the lowest serial number available. is the most recent serial number available.

%ERROR:402: not authorised to mirror the database
See section 2.8 "Access control for queries" for more information. One may use "-q sources" query to get more information about the NRTM source.

%ERROR:403: unknown source
The database identified by the

is not served by the server. Use "-q sources" for a list of available sources.

 


A2.5 Referral text

%REFERRAL START
After this line, output of the referred host starts.

% The object shown below is NOT in the %s database.
% It has been obtained by querying a remote server:
% cctld.dom.int at port 43.
% To see the object stored in the %s database
% use the -R flag in your query
%

%REFERRAL START

%REFERRAL END

Referral trailer, which frames the output of the referred host.

A3. Copyright information

A3.1 AFRINIC Database copyright

The information in the AFRINIC Database is available to the public for agreed Internet operation purposes, but is under copyright. The copyright statement is:

"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 AFRINIC

on behalf of the copyright holders. Any use of this material to target advertising or similar activities is explicitly forbidden and may be prosecuted. The AFRINIC requests to be notified of any such activities or suspicions thereof."

A3.2 RFC copyright statement

A RFC document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTSR ANY IMPLIED WARRANTIES OF ERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

A3.3 AFRINIC copyright

© AFRINIC 2005

Acknowledgements

The authors wish to acknowledge the effort done by the developers of the version 3.0 of the RIPE Database at the RIPE NCC: Daniele Arena, Marek Bukowy, Engin Gunduz, Roman Karpiuk, Shane Kerr, A.M.R. Magee, Chris Ottrey and Filippo Portera.

References

[1] C. Alaettinoglu, C. Villamizar, E. Gerich , D. Kessens,
D. Meyer, T. Bates, D. Karrenberg and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999.

[2] C. Villamizar, C. Alaettinoglu, D. Meyer and S. Murphy, "Routing Policy System Security", RFC 2725, December 1999.

[3] D. Meyer, J. Schmitz, C. Orange, M. Prior, and C. Alaettinoglu, "Using RPSL in Practice", RFC 2650, August 1999.

[4] T. Bates, E. Gerich , L. Joncheray, J.M. Jouanigot, D. Karrenberg, M. Terpstra and J. Yu, "Representation of IP Routing Policies in a Routing Registry", AFRINIC-181, October 1994. See http://www.ripe.net/docs/AFRINIC-181.html

[5] The "AFRINIC Database User's Manual" and the "AFRINIC Database Operations Manual" are scheduled to be written.

[6] RAToolset. See http://www.isi.edu/ra/RAToolSet/

[7] P. Mockapetris, "Domain names - Concepts and Facilities", RFC 1034, November1987.

[8] P. Resnick, ed., "Internet Message Format", RFC 2822, April 2001.

[9] J. Zsako, "PGP Authentication for AFRINIC Database Updates", RFC 2726, December 1999.

[10] ) N. Nimpuno, A.Robachevsky, "New Value of the "status:" Attribute for Inetnum Objects (LIR-PARTITIONED)", ripe-239, June2002.

[11] A. Cormack, D. Stikvoort, W. Woeber, and A. Robachevsky, "IRT Object in the AFRINIC Database" ripe-254, July 2002

[12] K. Harrenstien, M.K. Stahl, E.J. Feinler."NICNAME/WHOIS", RFC 954, October 1985.

[13] J.S.L. Damas and L. Vegoda, "New Values of the "status:" Attribute for inet6num Objects", ripe-243, August 2