Tony Bates <Tony.Bates@ripe.net> writes: * Okay, one immediate change that comes to mind is that the OPTIONAL [Local AS] information in the ifaddr attrbiute should be moved . It should in fact move out of ifaddr into peer information as I think the only time this will be used is actually at the routing/policy level rather than the interface level. Here is an updated draft with the modified syntax.

Other comments/corrections below...

--Tony.

Specifying an `Internet Router' in the Routing Registry

Tony Bates

DRAFT - DRAFT - DRAFT

Document ID: ripe-xy

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 are evolving that there is a need to register some details of an Internet router (1) within the routing registry. By adding this kind of detailed information it adds functionality to information based on routing policies [1] facilitating the ability to build operational tools [2],[3] such as configuration 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.

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 paper. _________________________ (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-xy.txt July, 1994  - 2 -

3. Router Representation

The representation must be capable of representing both ``interior'' and ``border'' routers within ones own autonomous system. 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 ifaddr: 192.87.4.28 ifaddr: 193.0.0.222 peer: 192.87.45.6 AS2122 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 peer: 192.87.4.5 AS3333 IBGP4 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 three configured inter- faces. You also see that it has several exterior peers and one inte- rior peer (192.87.45.6). Details of the actual routing protocol are given. This can be extremely useful. For example a BGP3 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 con- tact when problems occur with this router.

The example should list also interior peers with internal routing protocols and the explanation text should mention that too.

ripe-xy.txt July, 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] maintainer: [optional] [single] 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-xy.txt July, 1994  - 4 -

ifaddr: An interface address within the router.

Format: <Interface Address>

<Interface Address> must be a "dotted-quad" represented host address. It should be noted that at least ONE ifaddr must be configured for the inet-rtr object to be valid. This facilitates the registering of route servers which may only have one interface address and are purely routing engines.

Uhmmm, a route server which does not route packets but is only used by actual routers as a source of routing information IS NOT a router. Does it need to be registered? If yes I think it should be clearly distinguishable by actual routers.

Examples:

ifaddr: 192.87.45.190 ifaddr: 192.87.4.99 AS1755

^^^^^^ This should be removed after the mod from Tony, right?

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 the following reserved routing protocol keywords:

EGP The routers are using the exterior gateway protocol, EGP [7].

BGP The routers are using the exterior gateway protocol, BGP conforming to [8]. This can mean either BGP ver- sion 2 or BGP version 3.

BGP4 The routers are using the exterior gateway protocol, BGP conforming to BGP version 4 [9].

IBGP

ripe-xy.txt July, 1994  - 5 -

The routers are using the exterior gateway protocol, BGP as an interior routing protocol conforming to [8]. This can mean either BGP version 2 or BGP ver- sion 3.

IBGP4 The routers are using the exterior gateway protocol, BGP as an interior routing protocol conforming to BGP version 4 [9].

IDRP The routers are using the exterior gateway protocol, IDRP conforming to [10].

IGP This is an interior peering using a standard interior gateway protocol (i.e. RIP, OSPF, etc.).

OTHER This peering is using a protocol not in one of the categories above.

[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.

Text to be added: Note that in some cases a router configured as being in more than one AS can also peer with itself to exchange routes among its ASes

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

ripe-xy.txt July, 1994  - 6 -

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.

The meaning and usage of this attribute is not clear: which kind of changes?

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

maintainer: The maintainer attribute contains a registered maintainer name.

The meaning and purpose of this attribute is not clear.

Format: <registered maintainer name>

Example:

maintainer: 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

ripe-xy.txt July, 1994  - 7 -

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-xy.txt July, 1994  - 8 -

5. References

[1] Bates, T., Gerich, E., Joncheray, L., Joanigot, J-M, Karren- berg, D., Terpstra, M, Yu, J., ripe-81++, July 1994. WORK IN PROGRESS

[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)", <draft-ietf-bgp-bgp4-10.txt>, INTERNET DRAFT, May, 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.

ripe-xy.txt July, 1994

-- ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------

Tony,

bonito@nis.garr.it (Antonio_Blasco Bonito) writes:

* * The example should list also interior peers with internal routing protocols * and the explanation text should mention that too. * Well it does have an IBGP interior example. I can add something in the text as well.

I meant IGP should be there too. Usually you get information on internal routes via some IGP (OSPF, I-ISIS, RIP, IGRP, ...). It is wise to mention that in the example, I guess.

* > * > * > <Interface Address> must be a "dotted-quad" represented * > host address. It should be noted that at least ONE ifaddr * > must be configured for the inet-rtr object to be valid. * > This facilitates the registering of route servers which * > may only have one interface address and are purely routing * > engines. * * Uhmmm, a route server which does not route packets but is only used by * actual routers as a source of routing information IS NOT a router. Does it * need to be registered? If yes I think it should be clearly distinguishable * by actual routers. * Uhmmm..sorry not where I come from. A router is something that exchanges routing information - I see no reason why a router needs to forward packets. In fact a route server is specifically configured to not to forward packets. You are confusing routing with forwarding. I see no real reason to distinguish an RS. Whilst it is perhaps a special case it still fits simply into the general schema of the object. By having a single interface you give an indication of route serving (of course you can forward in and out of this as well but..). It is not the intent of this object to catch every special case (otherwise we have to support to ebgp multihop - tunnels, etc).

OK, this is terminology and "network philosophy". Leave as it is.

* * Text to be added: * Note that in some cases a router configured as being in more * than one AS can also peer with itself to exchange routes * among its ASes * Really ? what is the exact purpose of this and how is it acheived ?

Suppose you are running two BGP processes in a router you may want to run an IBGP between the two to echange routes eventually applying some policy filtering to the exchange. Exactly what is done if you have two different boxes...

* > * > notify: * > The notify attribute contains an email address to which notifi- * > cations of changes to this object should be send. * * The meaning and usage of this attribute is not clear: which kind of changes * ? * Any update - please look at the relavent ripe document for more details. ripe-096.txt btw.

OK, so please insert a reference to ripe-096 in the text.

* > * > maintainer: * > The maintainer attribute contains a registered maintainer name. *

* The meaning and purpose of this attribute is not clear.

See ripe-096 for more details.

OK, so please insert a reference to ripe-096 in the text.

--Tony.

---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------

Here the latest draft with the comments from Blasco. I would like to have this agreed at the latest at the next RIPE meeting. Comments are of course still welcome. However, I am about to depart for a month so they will have to wait to be folded in. --Tony. Specifying an `Internet Router' in the Routing Registry Tony Bates DRAFT - DRAFT - DRAFT Document ID: ripe-xy 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 are evolving that there is a need to register some details of an Internet router (1) within the routing registry. By adding this kind of detailed information it adds functionality to information based on routing policies [1] facilitating the ability to build operational tools [2],[3] such as configuration 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. 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 paper. _________________________ (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-xy.txt July, 1994  - 2 - 3. Router Representation The representation must be capable of representing both ``interior'' and ``border'' routers within ones own autonomous system. 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 ifaddr: 192.87.4.28 ifaddr: 193.0.0.222 peer: 192.87.45.6 AS2122 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 peer: 192.87.4.5 AS3333 IBGP4 peer: 192.87.4.2 AS3333 IGP 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 three configured inter- faces. You also see that it has several exterior peers and one inte- rior peer (192.87.45.6). Details of the actual routing protocol are given. This can be extremely useful. For example a BGP3 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 con- tact when problems occur with this router. ripe-xy.txt July, 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] maintainer: [optional] [single] 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-xy.txt July, 1994  - 4 - ifaddr: An interface address within the router. Format: <Interface Address> <Interface Address> must be a "dotted-quad" represented host address. It should be noted that at least ONE ifaddr must be configured for the inet-rtr object to be valid. This facilitates the registering of route servers which may only have one interface address and are purely routing engines. Examples: ifaddr: 192.87.45.190 ifaddr: 192.87.4.99 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 the following reserved routing protocol keywords: EGP The routers are using the exterior gateway protocol, EGP [7]. BGP The routers are using the exterior gateway protocol, BGP conforming to [8]. This can mean either BGP ver- sion 2 or BGP version 3. BGP4 The routers are using the exterior gateway protocol, BGP conforming to BGP version 4 [9]. IBGP ripe-xy.txt July, 1994  - 5 - The routers are using the exterior gateway protocol, BGP as an interior routing protocol conforming to [8]. This can mean either BGP version 2 or BGP ver- sion 3. IBGP4 The routers are using the exterior gateway protocol, BGP as an interior routing protocol conforming to BGP version 4 [9]. IDRP The routers are using the exterior gateway protocol, IDRP conforming to [10]. IGP This is an interior peering using a standard interior gateway protocol (i.e. RIP, OSPF, etc.). OTHER This peering is using a protocol not in one of the categories above. [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. 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 ripe-xy.txt July, 1994  - 6 - 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 Status: optional, multiple lines allowed maintainer: The maintainer attribute contains a registered maintainer name. See [11] for more details. Format: <registered maintainer name> Example: maintainer: RIPE-DBM Status: optional, multiple lines allowed remarks: Remarks/comments, to be used only for clarification. Format: free text Example: ripe-xy.txt July, 1994  - 7 - 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-xy.txt July, 1994  - 8 - 5. References [1] Bates, T., Gerich, E., Joncheray, L., Joanigot, J-M, Karren- berg, D., Terpstra, M, Yu, J., ripe-81++, July 1994. WORK IN PROGRESS [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)", <draft-ietf-bgp-bgp4-10.txt>, INTERNET DRAFT, May, 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., "Authorisation and Notification of Changes in the RIPE Database", ripe-096, Oct, 1993. ripe-xy.txt July, 1994