Specifying an `Internet Router' in the Routing
Registry
Tony Bates
Document ID: ripe-122
ABSTRACT
This paper describes a simple specification for
defining an Internet router within a routing registry.
1. Introduction
It has become apparent as routing registries evolve that there is a
need to register details of an Internet router (1) within the rout-
ing registry. By adding this kind of detailed information it adds
functionality to information based on routing policies [1] facili-
tating the ability to build operational tools [2],[3] such as confi-
guration generators and diagnostic tools within increased local
information. It also provides a direct method to find a contact for
an important component of the Internet infrastructure. This can be
extremely useful when resolving operational problems.
The features described in this document will be usable in the RIPE
database at a time specified in [17]. Please refer to this document
for more details.
2. Acknowledgments
This specification is based on a similar specification by Merit Inc.
for a `route' object (2). All credit should go to them. This paper
acts purely to clarify the original ideas set out in the Merit
_________________________
(1) Here an Internet router means any IP [4] node ca-
pable of running an IP routing protocol. Be that RIP,
BGP or any other of the current IP based routing proto-
cols found in the Internet today. This definition is
intentionally looser than what might be found in the
"Router requirements" Internet draft [5].
(2) This specification does not use `router' as the
object name to avoid possible clashes with the `route'
object which already exists within the routing regis-
try.
ripe-122.txt October, 1994
- 2 -
paper.
3. Router Representation
The representation must be capable of representing both ``interior''
and ``border'' routers within ones own autonomous system. This said,
it should be noted that the original intention of this object is to
document ones border routers but does preclude interior routers.
Each object is uniquely identified by its object name. Here is a
simple example of a router object:
inet-rtr: Amsterdam.ripe.net
localas: AS3333
ifaddr: 192.87.45.190 255.255.255.0
ifaddr: 192.87.4.28 255.255.255.0
ifaddr: 193.0.0.222 255.255.255.224
ifaddr: 193.0.0.158 255.255.255.224
peer: 192.87.45.6 AS3333 BGP4
peer: 193.0.0.219 AS2122 BGP
peer: 193.0.0.221 AS1104 BGP
peer: 192.87.4.18 AS1103 BGP4
peer: 192.87.4.24 AS1103 BGP4
peer: 192.87.4.20 AS286 BGP4
admin-c: Daniel Karrenberg
tech-c: Tony Bates
tech-c: Marten Terpstra
notify: ops@ripe.net
remarks: The router for the RIPE NCC
changed: tony@ripe.net 940720
source: RIPE
This object provides several key pieces of information. The exact
syntax for each attribute is discussed in the next section. However,
some general remarks about this example are worthy of note. From
this you can see immediately that this router "Amsterdam.ripe.net"
is in the autonomous system 3333 and has four configured interfaces.
You also see that it has several exterior peers and one interior
peer (192.87.45.6). Details of the actual routing protocol are
given. This can be extremely useful. For example a BGP3 (denoted
above by BGP) router is not CIDR [6] capable whereas a BGP4 capable
router is. A tool could use this information when examining routing
policy to see if a peer can make use of aggregation. Finally, we
also see who we can contact when problems occur with this router.
ripe-122.txt October, 1994
- 3 -
4. `inet-rtr' Syntax Definition
Here is a summary of the tags associated with inet-rtr object itself
and their status. The first column specifies the attribute, the
second column whether this attribute is mandatory in the inet-rtr
object, and the third column whether this specific attribute can
occur only once per object [single], or one or more [multiple]. When
specifying multiple lines per attribute, the attribute name must be
repeated.
inet-rtr: [mandatory] [single]
localas: [mandatory] [single]
ifaddr: [mandatory] [multiple]
peer: [optional] [multiple]
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:
inet-rtr:
The fully qualified domain name of the router.
Format:
Fully qualified domain name without trailing "." (dot).
This must be registered in the DNS. For routers with more
than one DNS you should pick the one that seems most suit-
able. It should be noted that it is commonly general prac-
tice for a router to have single uniquely defined domain
name.
Example:
inet-rtr: Amsterdam.ripe.net
Status: mandatory, only one line allowed
localas:
The autonomous system in which this router belongs.
Format:
AS<positive integer between 1 and 65535>
Example:
localas: AS3333
Status: mandatory, only one line allowed
ripe-122.txt October, 1994
- 4 -
ifaddr:
An interface address within the router.
Format:
<Interface Address> <Interface Subnet Mask>
<Interface Address> must be a "dotted-quad" represented
host address.
<Interface Mask> must be the "dotted-quad" subnet mask of
the interface address.
It should be noted that at least ONE ifaddr must be con-
figured for the inet-rtr object to be valid. This facili-
tates the registering of route servers which may only have
one interface address and are purely routing engines.
Examples:
ifaddr: 192.87.45.190 255.255.255.0
ifaddr: 192.87.4.99 255.255.255.0
Status: mandatory, multiple lines allowed
peer:
Details of any router peerings. These can be both interior or
exterior.
Format:
<Peer address> <Peer AS> <Routing Protocol> [Local AS]
<Peer address> is the interface address of the remote
peer. This is same format as that used in the ``ifaddr''
attribute above.
<Peer AS> is the autonomous system number of the peer. Its
format is AS<positive integer between 1 and 65535>. It
should be noted that even interior peers should have their
<Peer AS> detailed.
<Routing Protocol> represents the routing protocol running
between the router and the peer. This can be any one of a
list of reserved routing protocol keywords as given in
appendix A:
[Local AS] is an optional piece of information which
allows this peering to be configured as having the router
in a DIFFERENT autonomous system. This is useful only
when a router is configured to `fake' that it is another
AS. The format of [Local AS] is "localas AS<positive
integer between 1 and 65535>". The string `localas' must
be present for this optional information to be valid.
This is only useful with protocols that allow this
feature.
ripe-122.txt October, 1994
- 5 -
Example:
peer: 193.0.0.219 AS2122 BGP
peer: 193.0.0.221 AS1104 BGP
peer: 192.87.4.18 AS1103 BGP4
peer: 192.87.4.24 AS1103 BGP4
peer: 192.87.4.20 AS286 BGP4
peer: 192.87.4.6 AS2122 BGP4 localas AS2121
Status: optional, multiple lines allowed
admin-c:
Full name or uniquely assigned NIC-handle of an administrative
contact person.
Format:
<firstname> <initials> <lastname> or <nic-handle>
Examples:
admin-c: Joe T Bloggs
admin-c: JTB1
Status: mandatory, multiple lines allowed
tech-c:
Full name or uniquely assigned NIC-handle of a technical con-
tact 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
notify:
The notify attribute contains an email address to which notifi-
cations of changes to this object should be send. See [11] for
more details.
Format:
<email-address>
The <email-address> should be in RFC822 domain syntax
wherever possible. see
Example:
notify: Marten.Terpstra@ripe.net
ripe-122.txt October, 1994
- 6 -
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
remarks:
Remarks/comments, to be used only for clarification.
Format:
free text
Example:
remarks: This is a router
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
ripe-122.txt October, 1994
- 7 -
5. References
[1] Bates, T., Gerich, E., Joncheray, L., Joanigot, J-M, Karren-
berg, D., Terpstra, M, Yu, J., "Representation of IP Routing
Policies in the RIPE Database", RIPE-181, Oct, 194.
[2] PRIDE Tools Release 1.
See ftp.ripe.net:pride/tools/pride-tools-1.tar.Z.
[3] Merit Inc. RRDB Tools.
See rrdb.merit.edu:pub/meritrr/*
[4] J. Postel, "Internet Protocol", RFC 791, January 1981.
[5] Kastenholz, F., draft-ietf-rreq-iprouters-require-01.txt,
April, 1994, INTERNET DRAFT
[6] V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain
Routing (CIDR): an Address Assignment and Aggregation Stra-
tegy", RFC1519, Sep., 1993.
[7] Mills, D., "Exterior Gateway Protocol formal specification",
RFC904, April 1984.
[8] K. Lougheed, Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)",
RFC1267, October 1991.
[9] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC1654, January, 1994.
[10] C. Kunzinger, "ISO/IEC 10747 - Protocol for the Exchange of
Inter-Domain Routing Information among Intermediate Systems to
Support Forwarding of ISO 8473 PDUs", <draft-kunzinger-idrp-
ISO10747-00.txt>, INTERNET DRAFT, April 1994.
[11] Karrenberg, D., Terpstra, M. "Authorisation and Notification of
Changes in the RIPE Database", RIPE-120, Oct, 1994.
[12] Hedrick, C., "Routing Information Protocol", RFC1058, June,
1988.
[13] Malkin, G., "RIP Version 2 Protocol Analysis", RFC1387, June,
1993.
[14] Mills, D., "DCN local-network protocols", RFC891, December,
1983.
[15] Moy, J., "OSPF Version 2", RFC1583, March, 1994.
[16] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments", RFC1195, December, 1990.
[17] Bates, T., Karrenberg, D., Terpstra, T., "RIPE Database Transi-
tion Plan", RIPE-123, Oct, 1994.
ripe-122.txt October, 1994
- 8 -
6. Appendix A - List of Routing Protocol Keywords
This is a list of currently supported routing protocols supported in
the "inter-rtr" object. This list will be updated regularly in the
form of addenda to this document. Where a specification document
exists it is referenced.
EGP
The routers are using the exterior gateway protocol, EGP [7].
BGP
The routers are using the exterior gateway protocol, BGP, con-
forming to [8]. This can mean either BGP version 2 or BGP ver-
sion 3.
BGP4
The routers are using the exterior gateway protocol, BGP, con-
forming to BGP version 4 [9].
IDRP
The routers are using the exterior gateway protocol, IDRP, con-
forming to [10].
RIP
The routers are using the interior routing protocol, RIP [12]
RIP2
The routers are using the interior routing protocol, RIP2 [13]
HELLO
The routers are using the HELLO [14] protocol.
IGRP
The routers are using IGRP protocol from Cisco Systems Inc.
EIGRP
The routers are using EIGRP rotocol from Cisco Systems Inc.
OSPF
The routers are using the interior routing protocol, OSPF2
[15].
ISIS
The routers are using the IS-IS routing protocol [16].
OTHER
This peering is using a protocol not in one of the categories
above.
ripe-122.txt October, 1994