RIPE Database Reference Manual
(объекты базы данных, защита объектов (извлечение из ripe-252))
Документ: ripe - 252
1.2 Object types
This section describes object types (classes) supported in the RIPE Database
along with the object templates. The following definitions are used in the
templates:
1.2
[mandatory]
At least one instance of this attribute must be defined in
an object of the class.
[optional]
Attribute is optional in the objects of the class and can
be omitted.
[generated]
Attribute is automatically generated by the server.
[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.
[primary key] Attribute is (part of) the primary key.
[primary/look-up key]
Attribute is both indexed and is (part of) the primary key.
In an object template the first column represents an attribute, the second and
third columns specify the type of the attribute and the fourth column tells
whether the attribute is (part of) a database key for the object.
1.2.1 as-block
An as-block object is needed to delegate a range of AS numbers to a given
repository. This object may be used for authorisation of the creation of
aut-num objects within the range specified by the "as-block:" attribute. The
template of as-block class is shown in Figure 1.2.1.
as-block: [mandatory] [single] [primary/look-up key]
descr: [optional] [multiple] [ ]
remarks: [optional] [multiple] [ ]
tech-c: [mandatory] [multiple] [inverse key]
admin-c: [mandatory] [multiple] [inverse key]
notify: [optional] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.1 as-block template
1.2.2 as-set
An as-set object defines a set of aut-num objects. The attributes of the as-set
class are shown in Figure 1.2.2. The "as-set:" attribute defines the name of
the set. It is an RPSL name that starts with "as-". The "members:" attribute
lists the members of the set. The "members:" attribute is a list of AS numbers,
or other as-set names.
as-set: [mandatory] [single] [primary/look-up key]
descr: [mandatory] [multiple] [ ]
members: [optional] [multiple] [ ]
mbrs-by-ref: [optional] [multiple] [inverse key]
remarks: [optional] [multiple] [ ]
tech-c: [mandatory] [multiple] [inverse key]
admin-c: [mandatory] [multiple] [inverse key]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.2 as-set template
1.2.3 aut-num
An object of the aut-num class is a database representation of an Autonomous
System (AS), which is a group of IP networks operated by one or more network
operators that has a single and clearly defined external routing policy.
Objects of this class are used to specify routing policies. The attributes of
the aut-num class are shown in Figure 1.2.3. The value of the "aut-num:"
attribute is the AS number of the AS described by this object. The "as-name:"
attribute is a symbolic name (in RPSL name syntax) of the AS. The import, export
and default routing policies of the AS are specified using the "import:",
"export:" and "default:" attributes, respectively.
aut-num: [mandatory] [single] [primary/look-up key]
as-name: [mandatory] [single] [ ]
descr: [mandatory] [multiple] [ ]
member-of: [optional] [multiple] [inverse key]
import: [optional] [multiple] [ ]
export: [optional] [multiple] [ ]
default: [optional] [multiple] [ ]
remarks: [optional] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
cross-mnt: [optional] [multiple] [inverse key]
cross-nfy: [optional] [multiple] [inverse key]
notify: [optional] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
mnt-routes: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.3 aut-num template
1.2.4 domain
The domainobject 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 a trailing " . "
. The template of this class is shown in Figure 1.2.4
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] [inverse key]
sub-dom: [optional] [multiple] [inverse key]
dom-net: [optional] [multiple] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [optional] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
refer: [optional] [single] [ ]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.4 domain template
1.2.5 filter-set
A filter-set object defines a set of routes that are matched by its filter. The
"filter-set:" attribute defines the name of the filter. It is an RPSL name that
starts with "fltr-". The "filter:" attribute defines the set's policy filter.
A policy filter is a logical expression which when applied to a set of routes
returns a subset of these routes. The template of this class is shown in Figure
1.2.5.
filter-set: [mandatory] [single] [primary/look-up key]
descr: [mandatory] [multiple] [ ]
filter: [mandatory] [single] [ ]
remarks: [optional] [multiple] [ ]
tech-c: [mandatory] [multiple] [inverse key]
admin-c: [mandatory] [multiple] [inverse key]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.5 filter-set template
1.2.6 inet6num
An inet6num object contains information on allocations and assignments of IPv6
address space. The template of this class is shown in Figure 1.2.6.
inet6num: [mandatory] [single] [primary/look-up key]
netname: [mandatory] [single] [lookup key]
descr: [mandatory] [multiple] [ ]
country: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
rev-srv: [optional] [multiple] [inverse key]
status: [generated] [single] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
mnt-irt: [optional] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.6 inet6num template
1.2.7 inetnum
An inetnum object contains information on allocations and assignments of IPv4
address space. The template of this class is shown in Figure 1.2.7.
inetnum: [mandatory] [single] [primary/look-up key]
netname: [mandatory] [single] [lookup key]
descr: [mandatory] [multiple] [ ]
country: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
rev-srv: [optional] [multiple] [inverse key]
status: [mandatory] [single] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
mnt-routes: [optional] [multiple] [inverse key]
mnt-irt: [optional] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.7 inetnum template
1.2.8 inet-rtr
Routers are specified using the inet-rtr class. The attributes of the inet-rtr
class are shown in Figure 1.2.8. The "inet-rtr:" attribute is a valid DNS name
of the router described. Each "alias:" attribute, if present, is a canonical DNS
name for the router. The "local-as:" attribute specifies the AS number of the
AS that owns/operates this router. The template of this class is shown in Figure
1.2.8.
inet-rtr: [mandatory] [single] [primary/look-up key]
descr: [mandatory] [multiple] [ ]
alias: [optional] [multiple] [ ]
local-as: [mandatory] [single] [inverse key]
ifaddr: [mandatory] [multiple] [lookup key]
peer: [optional] [multiple] [ ]
member-of: [optional] [multiple] [inverse key]
remarks: [optional] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.8 inet-rtr template
1.2.9 irt
An irt object represents a Computer Security Incident Response Team (CSIRT)
along with contact and security information. It may be referenced from inetnum
or inet6num objects to specify CSIRT responsible for handling computer and
network incidents for the address range. The name of the irt is an object name
that must start with "IRT-". The template of this class is shown in Figure
1.2.9.
irt: [mandatory] [single] [primary/look-up key]
address: [mandatory] [multiple] [ ]
phone: [optional] [multiple] [ ]
fax-no: [optional] [multiple] [ ]
e-mail: [mandatory] [multiple] [lookup key]
signature: [mandatory] [multiple] [ ]
encryption: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
auth: [mandatory] [multiple] [ ]
remarks: [optional] [multiple] [ ]
irt-nfy: [optional] [multiple] [inverse key]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.9 irt template
1.2.10 key-cert
A key-cert object is a database public key certificate that is stored on the
server and may be used with a mntner object for authentication when performing
updates. Currently only keys compliant with the proposed Open PGP Internet
standard [RFC 2440] are supported. The template of this class is shown in Figure
1.2.10.
key-cert: [mandatory] [single] [primary/look-up key]
method: [generated] [single] [ ]
owner: [generated] [multiple] [ ]
fingerpr: [generated] [single] [ ]
certif: [mandatory] [multiple] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.10 key-cert template
1.2.11 limerick
The limerick object represents a humorous poem that has five lines and the rhyme
scheme "aabba". The template of this class is shown in Figure 1.2.11.
limerick: [mandatory] [single] [primary/look-up key]
descr: [optional] [multiple] [ ]
text: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
author: [mandatory] [multiple] [inverse key]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.11 limerick template
1.2.12 mntner
Objects in the RIPE Database may be protected using mntner (pronounced
"maintainer") objects. A mntner object specifies authentication information
required to authorise creation, deletion or modification of the objects
protected by the mntner. Mntner objects are not created automatically, but are
forwarded to the RIPE Database Administration for manual processing. The
template of this class is shown in Figure 1.2.12. ¦
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] [inverse key]
mnt-nfy: [optional] [multiple] [inverse key]
auth: [mandatory] [multiple] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
referral-by: [mandatory] [single] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.12 mntner template
¦ Routing Policy System Security specification [2] also defines a
"auth-override:" attribute in the mntner object template. Together with
"referral-by:" attribute, they allow to modify the mntner in case it becomes
unresponsive. Being part of non-core functionality, this facility is not
implemented in the current version of the database system. Please see [2] for
more information.
1.2.13 peering-set
A peering-set object defines a set of peerings that are listed in its "peering:"
attributes. The "peering-set:" attribute defines the name of the set. It is an
RPSL name that starts with "PRNG-". The template of this class is shown in
Figure 1.2.13.
peering-set: [mandatory] [single] [primary/look-up key]
descr: [mandatory] [multiple] [ ]
peering: [mandatory] [multiple] [ ]
remarks: [optional] [multiple] [ ]
tech-c: [mandatory] [multiple] [inverse key]
admin-c: [mandatory] [multiple] [inverse key]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.13 peering-set template
1.2.14 person
A person object contains information about technical or administrative contact
responsible for the object where it is referenced. Once the object is created,
the value of the "person:" attribute cannot be changed. The template of this
class is shown in Figure 1.2.14.
person: [mandatory] [single] [lookup key]
address: [mandatory] [multiple] [ ]
phone: [mandatory] [multiple] [ ]
fax-no: [optional] [multiple] [ ]
e-mail: [optional] [multiple] [lookup 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] [ ]
Fig. 1.2.14 person template
1.2.15 role
The role class is similar to the person class. However, instead of describing
a human being, it describes a role performed by one or more human beings.
Examples include help desks, network monitoring centres, system administrators,
etc. A role object is particularly useful since often a person performing a
role may change; however the role itself remains. The "nic-hdl:" attributes of
the person and role classes share the same name space. Once the object is
created, the value of the "role:" attribute cannot be changed. The template of
this class is shown in Figure 1.2.15.
role: [mandatory] [single] [lookup key]
address: [mandatory] [multiple] [ ]
phone: [optional] [multiple] [ ]
fax-no: [optional] [multiple] [ ]
e-mail: [mandatory] [multiple] [lookup 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] [ ]
Fig. 1.2.15 role template
1.2.16 route
Each interAS route (also referred to as an interdomain route) originated by an
AS is specified using a route object. The "route:" attribute is the address
prefix of the route and the "origin:" attribute is the AS number of the AS that
originates the route into the interAS routing system. The "route:" and
"origin:" attribute pair constitutes the primary key. The template of this class
is shown in Figure 1.2.16.
route: [mandatory] [single] [primary/look-up key]
descr: [mandatory] [multiple] [ ]
origin: [mandatory] [single] [primary/inverse key]
holes: [optional] [multiple] [ ]
member-of: [optional] [multiple] [inverse key]
inject: [optional] [multiple] [ ]
aggr-mtd: [optional] [single] [ ]
aggr-bndry: [optional] [single] [ ]
export-comps: [optional] [single] [ ]
components: [optional] [single] [ ]
remarks: [optional] [multiple] [ ]
cross-mnt: [optional] [multiple] [inverse key]
cross-nfy: [optional] [multiple] [inverse key]
notify: [optional] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
mnt-routes: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.16 route template
1.2.17 route-set
A route-set object defines a set of routes that can be represented by route
objects or by address prefixes. In the first case, the set is populated by means
of the "mbrs-by-ref:" attribute, in the latter, the members of the set are
explicitly listed in the "members:" attribute. The "members:" attribute is a
list of address prefixes or other route-set names. Note that the route-set
class is a set of route prefixes, not of database route objects. The template of
this class is shown in Figure 1.2.17.
route-set: [mandatory] [single] [primary/look-up key]
descr: [mandatory] [multiple] [ ]
members: [optional] [multiple] [ ]
mbrs-by-ref: [optional] [multiple] [inverse key]
remarks: [optional] [multiple] [ ]
tech-c: [mandatory] [multiple] [inverse key]
admin-c: [mandatory] [multiple] [inverse key]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.17 route-set template
1.2.18 rtr-set
A rtr-set object defines a set of routers. A set may be described by the
"members:" attribute, which is a list of inet-rtr names, IPv4 addresses or other
rtr-set names. A set may also be populated by means of the "mbrs-by-ref:"
attribute, in which case it is represented by inet-rtr objects. The template of
this class is shown in Figure 1.2.18.
rtr-set: [mandatory] [single] [primary/look-up key]
descr: [mandatory] [multiple] [ ]
members: [optional] [multiple] [ ]
mbrs-by-ref: [optional] [multiple] [inverse key]
remarks: [optional] [multiple] [ ]
tech-c: [mandatory] [multiple] [inverse key]
admin-c: [mandatory] [multiple] [inverse key]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
Fig. 1.2.18 rtr-set template
3.6.1 Authorisation model
The mntner objects serve as a container to hold authentication filters. A
reference to a maintainer within another object defines authorisation to perform
operations on the object or on a set of related objects. Such reference is
provided by means of the "mnt-by:", "mnt-lower:", "mnt-routes:" and
"mbrs-by-ref:" attributes.
The maintainer contains one or more "auth:" attributes. Each "auth:" attribute
begins with a keyword identifying the authentication method followed by the
authentication information needed to enforce that method.
Authentication methods currently supported include the following:
Method Description
NONE No authorisation checks are performed.
MAIL-FROM This is a very weak authentication check and is discouraged.
The authentication information is a regular expression over
ASCII characters. The maintainer is authenticated if the
"From:" field in RFC 822 mail headers are matched by this
regular expression. Since mail header forgery is quite easy,
this is a very weak form of authentication.
CRYPT-PW This is a relatively weak form of authentication.
The authentication information is a fixed encrypted password
in UNIX crypt format. The maintainer is authenticated if the
transaction contains the clear text password of the
maintainer. Since the password is in clear text in
transactions, it can be captured by snooping. Since the
encrypted form of the password is exposed, it is subject to
password guessing attacks.
PGPKEY Strong form of authentication. The authentication information
is a signature identity pointing to a public key certificate,
which is stored in a separate object. The maintainer is
authenticated if the transaction is signed by the
corresponding private key. The RIPE NCC does not guarantee
that a key belongs to any specific entity; it is not a
certificate authority. Anyone can supply any public keys with
any ownership information to the database and these keys can
be used to protect other objects by checking that the update
comes from someone who knows the corresponding secret key.
3.6.2 Protection of individual objects
Individual objects can be protected with a mntner object. The mntner is
referenced by the "mnt-by:" attribute in the object. The attribute type is
multiple, so several mntners can protect the object.
Only those mntners referenced by the "mnt-by:" attributes are authorised to
modify or delete the object. Note that authentication checks are OR-ed, so if at
least one mntner is authenticated, the operation is authorised. That means that
object protection is as weak as the weakest authentication method used in the
mntners referenced by the object.
When the "mnt-by:" attribute is added to an object for the first time (as part
of object creation or modification), the operation should pass authentication
checks for the mntner(s) referenced by this attribute.
3.6.3 Protection of aut-num object space
Protection of aut-num object space is done using an as-block class. The mntner
that authorises the creation of more specific as-block objects or aut-num
objects is specified by the "mnt-lower:" attribute of the as-block object. When
no "mnt-lower:" attribute is specified, the "mnt-by:" attribute is used.
3.6.4 Protection of address space
Address space allocations and assignments are represented by theinetnum and
inet6num objects. The "mnt-lower:" attribute is used to reference a mntner that
authorises the creation of more specific inetnum or inet6num objects. When no
"mnt-lower:" attribute is specified, the address space is unprotected.
3.6.5 Protection of route object space
The route object creation must satisfy several authentication criteria. It must
match the authentication specified in the aut-num and the authentication
specified in either a route object or, if no applicable route object is found,
then an inetnum. Finally the creation must be authorised by the maintainer of
the route object itself referenced by the "mnt-by:" attribute of the object.
When checking for prefix authorisation, an exact route object prefix match is
checked for first. If there is no exact match, then a longest prefix match that
is less specific than the prefix is searched for. If the route prefix search
fails, then a search is performed for an inetnum object that exactly matches the
prefix or for the most specific inetnum object that is less specific than the
route object submission. The aut-num object used for authentication checks is
referenced by the "origin:" attribute of the route object.
A route object must pass authorisation from both the referenced aut-num object
and the route or inetnum object. Authorisation shall be tested using the
maintainer(s) referenced in the "mnt-routes:" attribute(s) first. If that check
fails, the "mnt-lower:" attributes are checked. If that check fails, the
"mnt-by:" attributes are used for the authorisation check.
3.6.6 Protection of objects with hierarchical names
Many RPSL objects do not have a natural hierarchy of their own but allow
hierarchical names. Some examples are the object types as-set and route-set.
An as-set may have a name corresponding to no naming hierarchy such as "AS-Foo"
or it may have a hierarchical name of the form "AS1:AS-BAR".
When a hierarchical name is not used, authorisation for objects such as as-set
and route-set correspond to the rules for individual objects described in
section 3.6.2 "Protection of individual objects".
If hierarchical names are used, then the addition of an object must be
authorised by the aut-num whose key is named by everything to the left of the
rightmost colon in the name of the object being added.
Authorisation is determined by first using the "mnt-lower:" maintainer reference
or, if absent, by using the "mnt-by:" reference.
3.6.7 Protection of domain object space
Protection of the domain object space is done with the "mnt-lower:" attribute.
When used in the domain object, this attribute references the mntner that
authorises the creation of domain objects directly below in the domain tree
registered in the RIPE Database. For example, a top-level domain object (ccTLD)
protects the creation of the second-level domain objects, third-level domain
objects if there is no corresponding second-level domain object, etc. Note that
the top-level domain object (ccTLD or gTLD) cannot be created in the RIPE
Database by users, only by the Database administrator.
3.6.8 Protecting membership of a set
When membership of a set is specified through the use of the "member-of:"
attribute, the server checks the validity of the membership when creating or
updating an object-member. This "member-of:" 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.
However, specifying "member-of:" is not enough. The set object must also have a
"mbrs-by-ref:" attribute listing the maintainer of the object wanting to be a
member of the set. That is, the set owner must validate the membership claim of
an object with a "member-of:" attribute, and it does that by matching the mnt-by
line of the object with one of the maintainers in the "mbrs-by-ref:" attribute
of the set object. If the claim is not valid at the time when the server creates
or modifies an object-member (route, aut-num or inet-rtr), the operation fails.
If the "mbrs-by-ref:" attribute is missing, the set is defined explicitly by the
"members:" attribute.
3.6.9 Referencing an irt object
When adding a reference to an irt object, the update of an inetnum or inet6num
object should pass the following authorisation checks:
-from the irt object itself as specified in the "auth:" attribute
-from any of the mntner objects that protect the inetnum or inet6num
object.
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", ripe-181, October 1994. See
http://www.ripe.net/docs/ripe-181.html
[5] The "RIPE Database User's Manual" and the "RIPE 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 RIPE Database Updates", RFC
2726, December 1999.
[10] New value of the "status:" attribute for inetnum object available
soon
[11] The irt object in the RIPE Database available soon
|