contact person for this community.
Format:
<firstname> <initials> <lastname> or <nic-handle>
Example:
tech-c: John E Doe
tech-c: JED31
Status: mandatory, multiple lines allowed
admin-c:
Full name or uniquely assigned NIC-handle of an administrative
contact person. In many cases this would be the name of the
guardian.
Format:
<firstname> <initials> <lastname> or <nic-handle>
Example:
admin-c: Joe T Bloggs
admin-c: JTB1
Status: mandatory, multiple lines allowed
remarks:
Remarks/comments, to be used only for clarification.
Format:
free text
Example:
remarks: Temporary community
remarks: Will be removed after split into ASes
Status: optional, multiple lines allowed
notify:
The notify attribute contains an email address to which
notifications of changes to this object should be send. See also
[11].
Format:
<email-address>
The <email-address> should be in RFC822 domain syntax
wherever possible.
Example:
notify: Marten.Terpstra@ripe.net
Status: optional, multiple lines allowed
mnt-by:
The mnt-by attribute contains a registered maintainer name. See
also [11].
Format:
<registered maintainer name>
Example:
mnt-by: RIPE-DBM
Status: optional, multiple lines allowed
changed:
Who changed this object last, and when was this change made.
Format:
<email-address> YYMMDD
<email-address> should be the address of the person who
made the last change. YYMMDD denotes the date this change
was made.
Example:
changed: johndoe@terabit-labs.nn 900401
Status: mandatory, multiple lines allowed
source:
Source of the information.
This is used to separate information from different sources kept
by the same database software. For RIPE database entries the
value is fixed to RIPE.
Format:
RIPE
Status: mandatory, only one line allowed
Appendix C - AS Macros syntax definition.
Here is a summary of the tags associated with as-macro object itself
and their status. The first column specifies the attribute, the
second column whether this attribute is mandatory in the as-macro
object, and the third column whether this specific attribute can
occur only once per object [single], or more than once [multiple].
When specifying multiple lines per attribute, the attribute name must
be repeated. See [6] the example for the descr: attribute.
as-macro: [mandatory] [single]
descr: [mandatory] [multiple]
as-list: [mandatory] [multiple]
guardian: [mandatory] [single]
tech-c: [mandatory] [multiple]
admin-c: [mandatory] [multiple]
remarks: [optional] [multiple]
notify: [optional] [multiple]
mnt-by: [optional] [multiple]
changed: [mandatory] [multiple]
source: [mandatory] [single]
Each attribute has the following syntax:
as-macro:
The name of a macro containing at least two Autonomous Systems
grouped together for ease of administration.
Format:
AS-<string>
The <string> should be in upper case and not contain any
special characters.
Example:
as-macro: AS-EBONE
Status: mandatory, only one line allowed
descr:
A short description of the Autonomous System Macro.
Format:
free text
Example:
descr: Macro for EBONE connected ASes
Status: mandatory, multiple lines allowed
as-list:
The list of ASes or other AS macros that make up this macro. It
should be noted that recursive use of AS macros is to be
encouraged.
Format:
<aut-num> <as-macro> ...
See Appendix A for <aut-num> definition.
Example:
as-list: AS786 AS513 AS1104
as-list: AS99 AS-NORDUNET
Status: mandatory, multiple lines allowed
guardian:
Mailbox of the guardian of this AS macro.
Format:
<email-address>
The <email-address> should be in RFC822 domain format
wherever possible.
Example:
guardian: as-ebone-guardian@ebone.net
Status: mandatory, only one line and e-mail address allowed
tech-c:
Full name or uniquely assigned NIC-handle of a technical contact
person for this macro. This is someone to be contacted for
technical problems such as misconfiguration.
Format:
<firstname> <initials> <lastname> or <nic-handle>
Examples:
tech-c: John E Doe
tech-c: JED31
Status: mandatory, multiple lines allowed
admin-c:
Full name or uniquely assigned NIC-handle of an administrative
contact person. In many cases this would be the name of the
guardian.
Format:
<firstname> <initials> <lastname> or <nic-handle>
Examples:
admin-c: Joe T Bloggs
admin-c: JTB1
Status: mandatory, multiple lines allowed
remarks:
Remarks/comments, to be used only for clarification.
Format:
free text
Example:
remarks: AS321 will be removed from this Macro shortly
Status: optional, multiple lines allowed
notify:
The notify attribute contains an email address to which
notifications of changes to this object should be send. See also
[11].
Format:
<email-address>
The <email-address> should be in RFC822 domain syntax
wherever possible.
Example:
notify: Marten.Terpstra@ripe.net
Status: optional, multiple lines allowed
mnt-by:
The mnt-by attribute contains a registered maintainer name. See
also [11].
Format:
<registered maintainer name>
Example:
mnt-by: RIPE-DBM
Status: optional, multiple lines allowed
changed:
Who changed this object last, and when was this change made.
Format:
<email-address> YYMMDD
<email-address> should be the address of the person who
made the last change. YYMMDD denotes the date this change
was made.
Example:
changed: johndoe@terabit-labs.nn 900401
Status: mandatory, multiple lines allowed
source:
Source of the information.
This is used to separate information from different sources kept
by the same database software. For RIPE database entries the
value is fixed to RIPE.
Format:
RIPE
Status: mandatory, only one line allowed
Appendix D - Syntax for the "route" object.
There is a summary of the tags associated with route object itself
and their status. The first column specifies the attribute, the
second column whether this attribute is mandatory in the community
object, and the third column whether this specific attribute can
occur only once per object [single], or more than once [multiple].
When specifying multiple lines per attribute, the attribute name must
be repeated. See [6] the example for the descr: attribute.
route: [mandatory] [single]
descr: [mandatory] [multiple]
origin: [mandatory] [single]
hole: [optional] [multiple]
withdrawn: [optional] [single]
comm-list: [optional] [multiple]
remarks: [optional] [multiple]
notify: [optional] [multiple]
mnt-by: [optional] [multiple]
changed: [mandatory] [multiple]
source: [mandatory] [single]
Each attribute has the following syntax:
route:
Route being announced.
Format:
Classless representation of a route with the RIPE database
known as the "prefix length" representation. See [10] for
more details on classless representations.
Examples:
route: 192.87.45.0/24
This represents addressable bits 192.87.45.0 to
192.87.45.255.
route: 192.1.128.0/17
This represents addressable bits 192.1.128.0 to
192.1.255.255.
Status: mandatory, only one line allowed
origin:
The autonomous system announcing this route.
Format:
<aut-num>
See Appendix A for <aut-num> syntax.
Example:
origin: AS1104
Status: mandatory, only one line allowed
hole:
Denote the parts of the address space covered this route object
to which the originator does not provide connectivity. These
holes may include routes that are being currently routed by
another provider (e.g., a customer using that space has moved to
a different service provider). They may also include space that
has not yet been assigned to any customer.
Format:
Classless representation of a route with the RIPE database
known as the "prefix length" representation. See [10] for
more details on classless representations. It should be
noted that this sub-aggregate must be a component of that
registered in the route object.
Example:
hole: 193.0.4.0/24
Status: optional, multiple lines allowed
withdrawn:
Used to denote the day this route has been withdrawn from the
Internet routing mesh. This will be usually be used when a less
specific aggregate route is now routed the more specific (i.e.
this route) is not need anymore.
Format:
YYMMDD
YYMMDD denotes the date this route was withdrawn.
Example:
withdrawn: 940711
Status: optional, one line allowed.
comm-list:
List of one or more communities this route is part of.
Format:
<community> <community> ...
See Appendix B for <community> definition.
Example:
comm-list: HEP LEP
Status: optional, multiple lines allowed
remarks:
Remarks/comments, to be used only for clarification.
Format:
free text
Example:
remarks: Multihomed AS talking to AS1755 and AS786
remarks: Will soon connect to AS1104 also.
Status: optional, multiple lines allowed
notify:
The notify attribute contains an email address to which
notifications of changes to this object should be send. See also
[11].
Format:
<email-address>
The <email-address> should be in RFC822 domain syntax
wherever possible.
Example:
notify: Marten.Terpstra@ripe.net
Status: optional, multiple lines allowed
mnt-by:
The mnt-by attribute contains a registered maintainer name. See
also [11].
Format:
<registered maintainer name>
Example:
mnt-by: RIPE-DBM
Status: optional, multiple lines allowed
changed:
Who changed this object last, and when was this change made.
Format:
<email-address> YYMMDD
<email-address> should be the address of the person who
made the last change. YYMMDD denotes the date this change
was made.
Example:
changed: johndoe@terabit-labs.nn 900401
Status: mandatory, multiple lines allowed
source:
Source of the information.
This is used to separate information from different sources kept
by the same database software. For RIPE database entries the
value is fixed to RIPE.
Format:
RIPE
Status: mandatory, only one line allowed
Appendix E - List of reserved words
The following list of words are reserved for use within the
attributes of the AS object. The use of these words is solely for the
purpose of clarity. All keywords must be lower case.
accept
announce
exclude
from
to
transit
Examples of the usage of the reserved words are:
as-in: from <neighborAS> accept <route>
as-out: to <neighborAS> announce <route>
as-exclude: exclude <ASpath> to <destination>
as-transit: transit <ASpath> to <destination>
default: from <neighborAS> accept <route>
default: to <neighborAS> announce <route>
Note: that as-transit is an experimental attribute. See section 10.
Appendix F - Motivations for RIPE-81++
This appendix gives motivations for the major changes in this
proposal from ripe-81.
The main goals of the routing registry rework are:
SPLIT
Separate the allocation and routing registry functions into
different database objects. This will facilitate data management
if the Internet registry and routing registry functions are
separated (like in other parts of the world). It will also make
more clear what is part of the routing registry and who has
authority to change allocation vs. routing data.
CIDR
Add the possibility to specify classless routes in the routing
registry. Classless routes are being used in Internet
production now. Aggregation information in the routing registry
is necessary for network layer troubleshooting. It is also
necessary because aggregation influences routing policies
directly.
CALLOC
Add the possibility to allocate address space on classless
boundaries in the allocation registry. This is a way to preserve
address space.
CLEAN
To clean up some of the obsolete and unused parts of the routing
registry.
The major changes are now discussed in turn:
Introduce Classless Addresses
CIDR, CALLOC
Introduce route object.
SPLIT, CIDR and CALLOC.
Delete obsolete attributes from inetnum.
CLEAN.
Delete RIPE-DB and LOCAL from routing policy expressions.
CLEAN
Allow multiple ASes to originate the same route
Because it is being done. CIDR. Made possible by SPLIT.
Appendix G - Transition strategy from RIPE-81 to RIPE-81++
Transition from the routing registry described by ripe-81 to the routing
registry described in this document is a straightforward process once
the new registry functions have been implemented in the database
software and are understood by the most commonly used registry tools.
The routing related attributes in the classful inetnum objects of ripe-
81 can be directly translated into new routing objects. Then these
attributes can be deleted from the inetnum object making that object if
conform to the new schema.
Proposed transition steps:
1) Implement classless addresses and new object definition in the
database software.
2) Make common tools understand the new schema and prefer it if both
old and new are present.
3) Invite everyone to convert their data to the new format. This can
be encouraged by doing conversions automatically and proposing them
to maintainers.
4) At a flag day remove all remaining routing information from the
inetnum objects. Before the flag day all usage of obsoleted
inetnum attributes has to cease and all other routing registry
functions have to be taken over by the new objects and attributes.