RFC 1786
Representation of IP Routing Policies in a Routing Registry (ripe-81++)
Representation of IP Routing Policies in a Routing Registry (ripe-81++) 🎀
okay bestie, so this is RFC 1786 💖 It's an Informational RFC from March 1995, part of the Network Working Group, and it's not an Internet standard. It's basically a how-to for describing IP routing policies inside a routing registry 🧚 The title block has seven authors: T. Bates from MCI Telecommunications Corporation, E. Gerich, L. Joncheray and J. Yu from Merit, Inc., J-M. Jouanigot from CERN, D. Karrenberg from the RIPE NCC, and M. Terpstra from Bay Networks, Inc. 👑 The header doesn't list any RFC it obsoletes or updates. What it does say is that it's an update to the original ripe-81 proposal, and it also goes by the name ripe-81++ ✨
Status of this Memo 📜
this memo gives info to the Internet community 🦋 It does not specify an Internet standard of any kind, and distribution is unlimited, so share it with everyone 💅
Abstract 🌸
so this doc was first published as a RIPE document called ripe-181, and it's also being published as an Informational RFC so it can reach a bigger crowd 📣 It got a lot of love and acknowledgment across the Internet service provider community, and it's going to be the basic starting point for future work on Internet Routing Registries and routing policy representation 🔥 You can also call it ripe-81++. It's an update to the original ripe-81[1] proposal for representing and storing routing policies in the RIPE database, and it adds several extensions proposed by Merit Inc.[2] It also lays out a generalized IP routing policy representation that every Internet routing registry can use 🌈 Basically it's a tutorial AND a detailed guide to the database objects and attributes that make up a routing registry 🫶
Table of Contents 📋
Table of Contents
1. Introduction ................................................ 3
2. Organization of this Document ............................... 3
3. General Representation of Policy Information ............... 5
4. The Routing Registry and the RIPE Database .................. 11
5. The Route Object ............................................ 16
6. The Autonomous System Object ................................ 26
7. AS Macros ................................................... 36
8. The Community Object ........................................ 38
9. Representation of Routing Policies .......................... 41
10. Future Extensions .......................................... 50
11. References ................................................. 51
12. Security Considerations .................................... 52
13. Authors' Addresses ......................................... 53
Appendix A - Syntax for the "aut-num" object ................... 55
Appendix B - Syntax for the "community" object ................. 68
Appendix C - Syntax for the "as-macro" object .................. 72
Appendix D - Syntax for the "route" object ..................... 76
Appendix E - List of reserved words ............................ 80
Appendix F - Motivations for RIPE-81++ ......................... 81
Appendix G - Transition strategy ............................... 831. Introduction ✨
this doc is a super revised version of the RIPE routing registry doc called ripe-81 [1] 💅 Ever since it started in February 1993 with the RIPE routing registry, a bunch of additions and clarifications have popped up, and it's way cuter to present them all in one updated doc instead of a pile of separate addenda 🎀
some of the text is the same as the original ripe-81 doc, keeping its tutorial vibe mixed with details of the RIPE database objects for routing policy representation 🧚 This doc does NOT repeat the background and history from ripe-81, so if you want that, go check the original 📚 Also, even though this doc talks about the RIPE database and the RIPE routing registry specifically, you can totally swap in "Regional routing registry" wherever it says RIPE. The representation is general and flexible enough to work outside the RIPE community, and it pulls in lots of ideas from other routing registries 🌸
this doc was first published as a RIPE document called ripe-181, and it's also going out as an Informational RFC to reach a wider audience 🦋 It got huge interest and acknowledgment within the Internet service provider community, and it's going to be the starting point for future work on Internet Routing Registries and routing policy representation 🔥 You can also call it ripe-81++.
we need to give a shoutout to a lot of people who helped with this doc 🫶 Peter Lothberg co-wrote the original ripe-81 and shared so many ideas, and Gilles Farrache, Harvard Eidnes, Dale Johnson, Kannan Varadhan and Cengiz Alaettinoglu all gave super valuable input 💜 We also thank the RIPE routing working group for their review and comments, and Merit Inc. for loads of constructive feedback and for making the routing registry a worldwide Internet service 🌍 Last but not least, we thank the PRIDE project, which ran alongside the RARE Technical Program, RIPE and the RIPE NCC. Honestly, without their funding this paper wouldn't have happened 🙈
2. Organization of this Document 🍓
this doc works as both a basic tutorial for understanding routing policy AND a detailed guide to the objects and attributes an Internet routing registry uses to store routing policies 💖 Section 3 covers general issues about IP routing policies and how they're represented in routing registries. Experienced readers may wish to skip this section, no shade 😌 Section 4 gives an overview of the RIPE database: its basic concepts, its schema, and the objects that make up the database. It also highlights how the RIPE database splits routing information from allocation information 🧠 Sections 5, 6, 7 and 8 detail all the objects tied to routing policy representation. Section 9 is a pretty extensive "walk through" of how those objects get used to express routing policy, plus the general principles behind using them 🦋 Section 10 is supposed to provide a list of references used throughout the doc. Appendices A, B, C and D document the formal syntax for the database objects and attributes. Appendix F details the main changes from ripe-81 and the motivations for them, and Appendix G tackles the transition from ripe-81 to ripe-81++ 👑
heads up bestie 👀 the original text says Section 10 is where the references are listed, but the table of contents puts Future Extensions at Section 10 and References at Section 11. Just flagging it so you're not confused when you hop between them!
3. General Representation of Policy Information ✨
Networks, Network Operators and Autonomous Systems 🎀
Okay so first, let's get our vocab straight so nobody gets confused 💅 Throughout this document we try to stick to the same terms, bestie.
When we say "networks," we mean physical networks that have a unique classless IP network number. Those are Layer 3 entities. We do not mean organizations 🙈
The organizations operating networks are called "network operators." For the examples, we split network operators into two categories: "service providers" and "customers." A "service provider" is a network operator that runs a network to provide Internet services to different organizations, which are its "customers." The line between service providers and customers is not clear cut 🌸 A national research networking organization often acts as a service provider to Universities and other academic organizations, but in most cases it buys international connectivity from another service provider. A University networking department is a customer of the research networking organization, but in turn it may see University departments as its customers 💜
An Autonomous System (AS) is a group of IP networks with a single clearly defined routing policy, run by one or more network operators. Inside ASes, IP packets are routed using one or more Interior Routing Protocols (IGPs). In most cases, interior routing decisions are based on metrics derived from technical parameters like topology, link speeds and load.
The entity we call an AS is often more generally called a routing domain, with "AS" just being an implementation vehicle. We decided to use the term AS exclusively because it relates more directly to the database objects and routing tools. By using only one term, we hope to reduce the number of concepts and avoid confusion. The academically inclined reader may forgive us 🤭
ASes exchange routing information with other ASes using Exterior Routing Protocols (EGPs). Exterior routing decisions are frequently based on policy rules rather than purely technical parameters. Tools are needed to configure complex policies and to communicate those policies between ASes, while still ensuring proper operation of the Internet as a whole. Some EGPs, like BGP-3 [8] and BGP-4 [9], provide tools to filter routing information according to policy rules and more. None of them provides a mechanism to publish or communicate the policies themselves. Yet this is critical for operational coordination and fault isolation among network operators, and thus for the operation of the global Internet as a whole. This document describes a "Routing Registry" providing this functionality ✨
Routing Policies 🦋
The exchange of routing information between ASes is subject to routing policies. Consider the case of two ASes, X and Y, exchanging routing information:
NET1 ...... ASX <---> ASY ....... NET2ASX knows how to reach a network called NET1. It does not matter whether NET1 belongs to ASX or to some other AS that exchanges routing information with ASX either directly or indirectly. We just assume that ASX knows how to direct packets towards NET1. Likewise, ASY knows how to reach NET2.
In order for traffic from NET2 to NET1 to flow between ASX and ASY, ASX has to announce NET1 to ASY using an external routing protocol. This states that ASX is willing to accept traffic directed to NET1 from ASY. Policy thus comes into play first in the decision of ASX to announce NET1 to ASY.
In addition, ASY has to accept this routing information and use it. It is ASY's privilege to either use or disregard the information that ASX is willing to accept traffic for NET1. ASY might decide not to use this information if it does not want to send traffic to NET1 at all, or if it considers another route more appropriate to reach NET1.
So in order for traffic in the direction of NET1 to flow between ASX and ASY, ASX must announce it to ASY and ASY must accept it from ASX:
resulting packet flow towards NET1
<<===================================
|
|
announce NET1 | accept NET1
--------------> + ------------->
|
AS X | AS Y
|
<------------- + <--------------
accept NET2 | announce NET2
|
|
resulting packet flow towards NET2
===================================>>Ideally, and seldom practically, the announcement and acceptance policies of ASX and ASY are identical.
In order for traffic towards NET2 to flow, announcement and acceptance of NET2 must be in place the other way round. For almost all applications, connectivity in just one direction is not useful at all.
Usually policies are not configured for each network separately but for groups of networks. In practise, these groups are almost always defined by the networks forming one or more ASes.
Routing Policy limitations 🙈
It is important to realize that with current destination based forwarding technology, routing policies must eventually be expressed in these terms. It is relatively easy to formulate reasonable policies in very general terms which CANNOT be expressed in terms of announcing and accepting networks. With current technology, such policies are almost always impossible to implement.
The generic example of a reasonable but un-implementable routing is a split of already joined packet streams based on something other than destination address. Once traffic for the same destination network passes the same router, or the same AS at our level of abstraction, it will take exactly the same route to the destination (disregarding special cases like "type of service" routing, load sharing and routing instabilities).
In a concrete example, AS Z might be connected to the outside world by two links. AS Z wishes to reserve these links for different kinds of traffic, let's call them black and white traffic. For this purpose, the management of AS Z keeps two lists of ASes, the black and the white list. Together these lists comprise all ASes in the world reachable from AS Z.
"W"
<--->
... AS Z .... NET 3
<--->
"B"It is quite possible to implement the policy for traffic originating in AS Z: AS Z will only accept announcements for networks in white ASes on the white link and will only accept announcements for networks in black ASes on the black link. This causes traffic from networks within AS Z towards white ASes to use the white link, and likewise traffic for black ASes to use the black link.
Note that this way of implementing things makes it necessary to decide on the colour of each new AS which appears before traffic can be sent to it from AS Z. A way around this would be to accept only white announcements via the white link and to accept all but white announcements on the black link. That way, traffic from new ASes would automatically be sent down the black link, and AS Z management would only need to keep the list of white ASes rather than two lists.
Now for the unimplementable part of the policy. This concerns traffic towards AS Z. Consider the following topology:
B AS ---) "W"
W AS ---) --->
B AS ---)>> AS A ---> ... AS Z .... NET 3
B AS ---) --->
W AS ---) "B"As seen from AS Z, there are both black and white ASes "behind" AS A. Since ASes can make routing decisions based on destination only, AS A and all ASes between AS A and the two links connecting AS Z can only make the same decision for traffic directed at a network in AS Z, say NET 3. This means that traffic from both black and white ASes towards NET 3 will follow the same route once it passes through AS A. This will either be the black or the white route, depending on the routing policies of AS A and all ASes between it and AS Z.
The important thing to note is that unless routing and forwarding decisions can be made based on both source and destination addresses, policies like the "black and white" example cannot be implemented in general, because "once joined means joined forever."
Access Policies 🔐
Access policies, contrary to routing policies, are not necessarily defined in terms of ASes. The very simplest type of access policy is to block packets from a specific network S from being forwarded to another network D. A common example is when some inappropriate use of resources on network D has been made from network S and the problem has not been resolved yet. Other examples of access policies might be resources only accessible to networks belonging to a particular disciplinary group or community of interest. While most of these policies are better implemented at the host or application level, network level access policies do exist and are a source of connectivity problems which are sometimes hard to diagnose. Therefore, they should also be documented in the routing registry according to similar requirements as outlined above.
Routing vs. Allocation information 🧩
The RIPE database contains both routing registry and address space allocation registry information. In the past, the database schema combined this information. Because RIPE was tasked with running both an allocation and routing registry, it seemed natural to initially combine these functions. However, experience has shown that a clear separation of routing information from allocation is desirable. Often the maintainer of the routing information is not the same as the maintainer of the allocation information. Moreover, in other parts of the world there are different registries for each kind of information.
Whilst the actual routing policy objects will be introduced in the next section, it is worthy of note that a transition from the current objects will be required. Appendix G details the basic steps of such a transition.
This split in information represents a significant change in the representational model of the RIPE database. Appendix F expands on the reasons for this a little more.
Tools 🛠️
The network operators will need a series of tools for policy routing. Some tools are already available to perform some of the tasks. Most notably, the PRIDE tools [3] from the PRIDE project started in September 1993, as well as others produced by Merit Inc [4] and CERN [5].
These tools will enable them to use the routing policy stored in the RIPE routing registry to perform such tasks as check actual routing against policies defined, ensure consistency of policies set by different operators, and simulate the effects of policy changes.
Work continues on producing more useful tools to service the Internet community ✨
4. The Routing Registry and the RIPE Database ✨
okay so bestie, one of RIPE's big jobs 💅 is keeping a database of European IP networks, DNS domains, their contact people, and loads of other network management info 🦋. Anyone can query it with the whois protocol or grab the whole thing, which is so helpful for NICs/NOCs all over Europe and beyond 🫶.
The RIPE database is giving two-in-one energy 🎀. It combines an allocation registry and a routing registry. The allocation registry holds data about address space allocated to specific enterprises and/or delegated to local registries, plus data about the domain name space. Those docs are [6,7], and they're outside the scope of this one, so we're not going there today 🙈.
Database Objects
Each object in the database describes one single entity in the real world ✨. So info about that entity should only live in its own object and never get repeated in other objects, iykyk 💀. The whois service can automatically display referenced objects where it makes sense 🌸.
Here's the lineup of object types in the RIPE database 🍓:
R Object Describes References
____________________________________________________________________
B person contact persons
A inetnum IP address space person
A domain DNS domain person
R aut-num autonomous system person
(aut-num,community)
R as-macro a group of autonomous systems person, aut-num
R community community person
R route a route being announced aut-num, community
R clns CLNS address space and routing personThe first column tells you if the object is part of the allocation registry (A), the routing registry (R), or both (B) 🦋. The last column lists the object types that a given type references. And yeah, almost all objects reference contact persons, which is literally the vibe 💖.
Objects are attribute-value pairs, one per line, and objects are separated by empty lines 🧚. If an attribute runs across multiple lines, you repeat the attribute name on each consecutive line. The info stored about network 192.87.45.0 is three objects total: one inetnum object and two person objects. It looks like this:
inetnum: 192.87.45.0
netname: RIPE-NCC
descr: RIPE Network Coordination Centre
descr: Amsterdam, Netherlands
country: NL
admin-c: Daniel Karrenberg
tech-c: Marten Terpstra
rev-srv: ns.ripe.net
rev-srv: ns.eu.net
notify: ops@ripe.net
changed: tony@ripe.net 940110
source: RIPE
person: Daniel Karrenberg
address: RIPE Network Coordination Centre (NCC)
address: Kruislaan 409
address: NL-1098 SJ Amsterdam
address: Netherlands
phone: +31 20 592 5065
fax-no: +31 20 592 5090
e-mail: dfk@ripe.net
nic-hdl: DK58
changed: ripe-dbm@ripe.net 920826
source: RIPE
person: Marten Terpstra
address: RIPE Network Coordination Centre (NCC)
address: PRIDE Project
address: Kruislaan 409
address: NL-1098 SJ Amsterdam
address: Netherlands
phone: +31 20 592 5064
fax-no: +31 20 592 5090
e-mail: Marten.Terpstra@ripe.net
nic-hdl: MT2
notify: marten@ripe.net
changed: marten@ripe.net 931230
source: RIPEObjects get stored and retrieved in this tag/value format 💅. The RIPE NCC doesn't offer differently formatted reports, because any format you want can easily be produced from this generic one 🌈.
Routing Registry Objects
The main objects in the routing registry are "aut-num" and "route", which describe an autonomous system and a route respectively 🎀. Also, routes that aren't described in the routing registry should never be routed in the Internet itself 🙅♀️.
The autonomous system (aut-num) object gives contact info for the AS and describes that AS's routing policy 🌸. The policy is described by listing all the neighboring ASes that routing info gets exchanged with. For each neighbor, the policy spells out exactly what is being sent (announced) and what's allowed in (accepted) 📬. This is the part of the global policy an AS has direct control over, and that's the key bit 🔑. So each aut-num object describes what can actually be implemented and enforced locally by the AS. Put all the aut-num objects together and you get the global routing graph, which lets you work out the exact routing policy between any two ASes 🧚.
The aut-num objects describe how routing info gets propagated, while the route object describes a single route injected into the external routing mesh 🦋. The route object references the AS that injects (originates) the route, so it indirectly gives contact info for the originating AS too 💖. That reference is also the main way routes get grouped into bigger collections 🍓. Describing routing policy one route at a time would be awkward to impractical, given that the Internet had about 20,000 routes at the time of this writing 😭. So routing policy is mostly defined for groups of routes by originating AS 🫶. This grouping method is well supported by current exterior routing protocols ✨. The route object also references community objects (described below) for another way to group routes 💅. Modifying the aut-num object itself, and the references to it from route objects, is strictly protected, so network operators stay in control of their routing policy descriptions and the routes their ASes originate 🔐.
Sometimes even grouping routes at the AS level is cumbersome 🌀. Take policies described at the transit provider level, which apply transitively to all customers of that transit provider. That's why there's another layer of grouping: the as-macro object, which is a group of ASes that can be referenced in routing policies just like single ASes 👑. Membership of as-macro groups is also strictly controlled 🔒.
Sometimes you need to group routes by something other than ASes, for things like statistics or local access policies 📊. That's what the community object is for 🌈. A community object is basically an AS but without a routing policy. It just describes a group of routes 🎀. Exterior routing protocols don't support this at all, and depending on how routes get aggregated, it may not be generally usable for defining routing policies 🙈. It's best for local policies and non-routing purposes 🧚.
These routing-related objects will get the full treatment in the sections below 💖.
5. The Route Object 🌈
As we covered in the last chapter, routing info and address space allocation info are now clearly separated ✨. The route object is what made that happen, and it holds all the info about a routing announcement 📬.
All routing-related attributes have been removed from the inetnum object 🙅♀️. Some old attributes are obsoleted: connect, routpr-l, bdryg-l, nsf-in, nsf-out, gateway 🪦. The routing attributes that are still useful got moved to the route object: aut-sys becomes origin, ias-int gets encoded as part of the inet-rtr [15] object, and comm-list simply moves 🦋. See [6] for details on the "inetnum" object definition 📖.
Here's the old inetnum object, before the split:
inetnum: 192.87.45.0
netname: RIPE-NCC
descr: RIPE Network Coordination Centre
descr: Amsterdam, Netherlands
country: NL
admin-c: Daniel Karrenberg
tech-c: Marten Terpstra
connect: RIPE NSF WCW
aut-sys: AS3333
comm-list: SURFNET
ias-int: 192.87.45.80 AS1104
ias-int: 192.87.45.6 AS2122
ias-int: 192.87.45.254 AS2600
rev-srv: ns.ripe.net
rev-srv: ns.eu.net
notify: ops@ripe.net
changed: tony@ripe.net 940110
source: RIPEAnd here's how that gets distributed across two objects 🎀:
inetnum: 192.87.45.0
netname: RIPE-NCC
descr: RIPE Network Coordination Centre
descr: Amsterdam, Netherlands
country: NL
admin-c: Daniel Karrenberg
tech-c: Marten Terpstra
rev-srv: ns.ripe.net
rev-srv: ns.eu.net
notify: ops@ripe.net
changed: tony@ripe.net 940110
source: RIPE
route: 192.87.45.0/24
descr: RIPE Network Coordination Centre
origin: AS3333
comm-list: SURFNET
changed: dfk@ripe.net 940427
source: RIPEThe route object represents a single route originated into the Internet routing mesh 🌐. The actual syntax is in Appendix D 📚. A few attribute details are worth noting though 👀.
The value of the route attribute is a classless address 💅. It represents the exact route being injected into the routing mesh. Classless address representation is described in [10] 🧚.
The value of the origin attribute is an AS reference of the form AS1234, which refers to an aut-num object 🫶. It represents the AS injecting this route into the routing mesh. The aut-num object it points to (see below) gives all the contact info for this route 📬.
Special cases: Only a single originating AS can go in each route object 🚨. But in today's Internet, a route is sometimes injected by more than one AS 😬. That's potentially dangerous, because it can create conflicting routing policies for that route, and it needs coordination between the originating ASes 🫠. In the routing registry, this is represented by multiple route objects 🎀.
This is a departure from the one route (net), one AS principle of the ripe-81 routing registry 🦋. The consequences for the different tools based on the routing registry will need to be evaluated, and additional consistency checking of the database may be needed 🔍.
The examples below show the route object in action 🌸. Imagine three chunks of address space belonging to two different enterprises, represented by these inetnum objects 🏢:
Examples
inetnum: 193.0.1.0
netname: ENT-1
descr: Enterprise 1
...
inetnum: 193.0.8.0
netname: ENT-2
descr: Enterprise 2
...
inetnum: 193.0.9.0
netname: ENT-2-SPEC
descr: Enterprise 2
...Assuming the enterprises have their own AS numbers, straight application of routing without aggregation would give you this 💖:
route: 193.0.1.0/24
descr: Enterprise 1
origin: AS1
...
route: 193.0.8.0/24
descr: Enterprise 2
origin: AS2
...
route: 193.0.9.0/24
descr: Enterprise 2
origin: AS2
...NB: This representation can be achieved by straight translation from the ripe-81 representation. See Appendix G for more details 📖.
Homogeneous Aggregation
The two chunks of address space belonging to Enterprise 2 can be represented by one aggregate route 🧩. That turns two route objects into one, which can potentially save routing table space for one route 🍓:
route: 193.0.8.0/23
descr: Enterprise 2
origin: AS2
...Okay so AS2 could also decide to originate every route we've mentioned so far: two 24-bit prefixes and one 23-bit prefix 🧚. That would mean storing all three route objects in the database. ngl, in this example the extra routes don't add any real functionality, they just mean more routes get announced for no reason 💀
Heterogeneous Aggregation
Now let's look at a case that's a bit more chaotic 🌸
route: 193.0.8.0/24
descr: Enterprise 2
origin: AS2
...
route: 193.0.9.0/24
descr: Enterprise 2 / Special
origin: AS2
comm-list: SPECIAL
...So the prefix 193.0.9.0/24 belongs to community SPECIAL (which may well not matter for routing), and the other prefix AS2 originates doesn't. If AS2 aggregates these into 193.0.8.0/23, then routing policies based on the community value SPECIAL basically can't be implemented in general, because there's no way to tell the special part of AS2 apart from the not-so-special part 😩
If another AS wants a policy that accepts only routes to members of community SPECIAL, it's stuck too. Accepting the route to 193.0.8.0/23 would also route traffic to 193.0.8.0/24, but not accepting it would lose connectivity to the special part, 193.0.9.0/24. We call aggregate routes made of components from different communities, or even different ASes, heterogeneous aggregates 🦋
The big problem with heterogeneous aggregates is that once the homogeneous more specific routes get withdrawn, you can't tell whether a more specific part of the heterogeneous route has a different policy. That said, you could argue that knowing the policy isn't really useful anyway, since a policy based only on the less specific heterogeneous aggregate can't be implemented. Honestly this shows a facet of CIDR itself: you may trade off implementing slight policy variations for announcing a larger aggregate (even if it's heterogeneous in terms of policy) to save routing table space 🎀
Still, it's useful to be able to document these policy variations, especially when a homogeneous more specific route is just being withdrawn. For that you can use the "withdrawn" attribute. The withdrawn attribute can do two jobs: it can indicate that a less specific aggregate is actually heterogeneous, and it can also allow general documentation of route withdrawal ✨
So AS2 needs a way to document this even if it no longer originates the route to 193.0.9.0/24. This can be done with the "withdrawn" attribute of the route object. The aggregate route to 193.0.8.0/23 now gets registered as:
route: 193.0.8.0/23
descr: Enterprise 2
origin: AS2
...The two homogeneous routes get marked as withdrawn from the Internet routing mesh, but they keep their original routing information 🫶
route: 193.0.8.0/24
descr: Enterprise 2
origin: AS2
withdrawn: 940701
...
route: 193.0.9.0/24
descr: Enterprise 2 / Special
origin: AS2
comm-list: SPECIAL
withdrawn: 940701
...Also, the date value used in the withdrawn attribute can only be in the past 📅
Proxy Aggregation
Next up are aggregates made of more than one AS. This generally means one AS is aggregating on behalf of another, and that's called proxy aggregation 👑 Proxy aggregation should be done with great care and always be coordinated with the other providers announcing the same route, bestie 🫣
Check this out:
route: 193.0.0.0/20
descr: All routes known by AS1 in a single package
origin: AS1
...
route: 193.0.1.0/24
descr: Foo
origin: AS1
withdrawn: 940310
...
route: 193.0.8.0/24
descr: Bar
origin: AS2
withdrawn: 940310
...
route: 193.0.9.0/24
descr: Bar-2
origin: AS2
withdrawn: 940310
comm-list: SPECIAL
...If AS1 announced no other routes to a single homed neighboring AS, that neighbor can generally either take the route or leave it, but it can't tell AS1 and AS2 apart 🙈
Note: If the neighbor was previously configured to accept routes originating in AS2 but not in AS1, they lose connectivity to AS2 as well. This means proxy aggregation has to be done carefully and in a well coordinated fashion. The information in the withdrawn route object can help with that 💅
Aggregates with Holes
Let's say the world of our example still has only three chunks of address space. The aggregate above then contains what are called holes: parts of an aggregate that aren't reachable via the originator of the route. From the routing information alone you can't tell whether something is a hole or which part of the route falls inside one. The only way to find out is to send a packet there and see whether it arrives, an ICMP message comes back, or there's silence 😶 On the other hand, announcing aggregates with holes is totally legitimate. Picture a 16-bit aggregate with just one 24-bit prefix unreachable: the savings in routing table size far outweigh the hole problem 🌈
For operational reasons, though, it's really useful to register these holes in the routing registry. Imagine a remote network operator having connectivity problems to addresses inside an aggregate route. If the packets reach the AS announcing the aggregate and there are no more specific routes, the normal course of action is to contact the originating AS of the aggregate and ask them to fix it. If the address falls into a hole, that's futile 😭 So problem diagnosis can be sped up and unnecessary calls prevented by registering the holes in the routing registry. We do this with the "hole" attribute. In our example, the representation would be:
route: 193.0.0.0/20
descr: All routes known by AS1
origin: AS1
hole: 193.0.0.0/24
hole: 193.0.2.0/23
hole: 193.0.4.0/22
hole: 193.0.10.0/23
hole: 193.0.12.0/22
...Note: there would also be two routes with the withdrawn attribute, as displayed above (i.e.193.0.8.0/24and193.0.9.0/24). It is not mandatory to document all holes. It is recommended that all holes routed by another service provider are documented.
Multiple Proxy Aggregation
Finally, suppose AS2 decides to announce the same aggregate as in the previous example. They would add the following route object to the registry:
route: 193.0.0.0/20
descr: All routes known by AS2
origin: AS2
hole: 193.0.0.0/24
hole: 193.0.2.0/23
hole: 193.0.4.0/22
hole: 193.0.10.0/23
hole: 193.0.12.0/22
...Both AS1 and AS2 will be notified that there's already a route to the same prefix in the registry 👀
This multiple proxy aggregation is very dangerous to do if the sub-aggregates of the route aren't the same. It's still dangerous when the sub-aggregates are consistent, but connectivity to the sub-aggregates varies widely between the originators 🚨
Route object update procedures
Adding a route object has to be authorised by the maintainer of the originating AS. How this is implemented is outside the scope of this document. This guarantees that an AS guardian has full control over the registration of the routes it announces [11] 👑
What is an Inter-AS network ?
An inter-AS network (Inter-AS IP networks are those networks currently called FIXes, IXFs, DMZs, NAPs, GIX and many other acronyms) exists for the purpose of passing traffic and routing information between different autonomous systems 🍓 The simplest example is a point-to-point link connecting exactly two ASes. Each end of such a link connects to an interface of a router belonging to each of the autonomous systems. More complex examples are broadcast type networks with multiple interfaces connecting multiple ASes, with the possibility of more than one connection per AS 🌸
Consider this example of three routers 1, 2 and 3 with interfaces a through f, connected by two inter-AS networks X and Y:
X Y
a1b --- c2d --- e3fSuppose network X is registered in the routing registry as part of AS1, and net Y as part of AS3. If traffic passes from left to right, prtraceroute will report this sequence of interfaces and ASes:
a in AS1
c in AS1
e in AS3The traceroute algorithm only enumerates the receiving interfaces on the way to the destination. In this example, that means the passage through AS2 goes unnoticed. This is confusing for the user, and it'll also generate exceptions when the path found is checked against the routing registry 😵💫
For operational monitoring tools like prtraceroute, it's necessary to know which interface on an inter-AS network belongs to which AS. If AS information isn't known about interfaces on an inter-AS network, tools like prtraceroute can't determine correctly which ASes are being traversed 🥺
All interfaces on inter-AS networks will are described in a separate object known as `inet-rtr' [15] ✨
6. The Autonomous System Object ✨
Autonomous Systems
okay so an Autonomous System (AS) is a group of IP networks run by one or more network operators, and it has a single, clearly defined external routing policy 🎀
Every AS gets a unique number 🔢 That number is used when swapping exterior routing info and also works as the AS's own ID. Exterior routing protocols like BGP and EGP are how ASes trade routing information with each other 🦋
In routing terms, an AS will normally run one or more interior gateway protocols (IGPs) together with some sort of common agreed metrics when it shares network info inside its own AS 💅
Here's the tea: people constantly mix up "AS" with a convenient way to group networks that sit under the same administrative umbrella, even when those networks have totally different routing policies inside the group 🙈 For that situation we have the "community" concept. An AS can strictly have only one single external routing policy, so don't use it as a catch-all bucket 😭
The creation of an AS should be done in a conscious and well coordinated way, so you don't end up making ASes just for the sake of it 💀 The worst case is one AS per routing announcement, which is chaos. Also, there is a limited number of AS numbers available 🍓 Creating an AS may also increase the number of AS paths that modern EGPs have to keep track of, and that makes the thing known as "the routing table growth problem" even worse 📈 So applying the general rules for creating and allocating an AS (listed below) may mean some re-engineering is needed. Still, that may be the only way to actually implement the routing policy you want anyway ✨ The creation and allocation of an AS should be done with these recommendations in mind:
- Creation of an AS is only required when exchanging routing information with other ASes. Some router implementations use an AS number as a form of tagging to identify the routing process. Just know that this tag does not need to be unique unless routing information is actually exchanged with other ASes 🏷️
- For a simple case of customer networks connected to a single service provider, the IP network should normally be a member of the service providers AS. In terms of routing policy, the IP network has exactly the same policy as the service provider, so there's no need to make any distinction in routing information. This idea may seem slightly alien to some at first, but it highlights the clear distinction between using the AS number as a representation of routing policy and using it for some form of administrative purpose 🧚
- If a network operator connects to more than one AS with different routing policies, then they need to create their own AS. In the case of multi-homed customer networks connected to two service providers, there are at least two different routing policies to a given customer network. At this point the customer networks will be part of a single AS, and this AS would be distinct from either of the service providers ASes. This lets the customer have a different representation of policy and preference to each of the service providers 👑 This is the ONLY case where a network operator should create its own AS number 🫶
- As a general rule, one should always try to populate the AS with as many routes as possible, as long as all routes conform to the same routing policy 🌈
Each AS is represented in the RIPE database by both an aut-num object and the route objects representing the routes originated by the AS 🗂️ The aut-num object stores descriptive, administrative and contact information about the AS, plus the routing policies of the AS in relation to all neighboring ASes.
The origin attributes of the route objects define the set of routes originated by the AS. Each route object can have exactly one origin attribute. Route objects can only be created and updated by the maintainer of the AS, not by those immediately responsible for the particular routes referenced in them. This ensures that operators, especially service providers, stay in control of AS routing announcements 👑
The AS object itself is used to represent a description of the AS's administrative details and routing policies. The AS object definition looks like this:
Example:
aut-num: AS1104
descr: NIKHEF-H Autonomous system
as-in: from AS1213 100 accept AS1213
as-in: from AS1913 100 accept AS1913
as-in: from AS1755 150 accept ANY
as-out: to AS1213 announce ANY
as-out: to AS1913 announce ANY
as-out: to AS1755 announce AS1104 AS1913 AS1213
tech-c: Rob Blokzijl
admin-c: Eric Wassenaar
guardian: as-guardian@nikhef.nl
changed: ripe-dbm@ripe.net 920910
source: RIPESee Appendix A for a complete syntax definition of the "aut-num" object 📖
It should be noted that this representation provides two things:
- a set of routes.
- a description of administrative details and routing policies.
The set of routes can be used to generate network list based configuration information, as well as configuration information for exterior routing protocols that know about ASes. This means an AS can be defined and is useful even if it does not use routing protocols which know about the AS concept 🦋
Description of routing policies between ASs with multiple connections - "interas-in/interas-out"
The following section is only relevant for ASes which use different policies on multiple links to the same neighboring AS. Readers not doing this may want to skip this section.
Description of multiple connections between ASs defines how two ASs have chosen to set different policies for the use of each or some of the connections between them. This description is only necessary if the ASs are connected in more than one way and the routing policy differs at these two connections 🌸
Example:
LINK1
193.0.1.1 +----------+ 193.0.1.2
| |
AS1------AS2== ==AS3-----AS4
| |
193.0.1.5 +----------+ 193.0.1.6
LINK2Note: LINK here denotes the peer connection points between ASs. It is not necessarily just a serial link. It could be ethernet or any other type of connection as well. It can also be a peer session where the address is the same at one end and different at the other end.
It may be that AS2 wants to use LINK2 only for traffic towards AS4. LINK1 is used for traffic to AS3, and as backup to AS4 should LINK2 fail 🔥 To implement this policy, one would use the attributes "interas-in" and "interas-out." These attributes let ASs describe their local decisions based on their preference, such as multi-exit-discriminators (MEDs) as used in some inter-domain routing protocols (BGP4, IDRP), and communicate those routing decisions. This information would be useful in resolving problems when some traffic paths changed from traversing AS3's gateway in Timbuktu rather than the gateway in Mogadishu 🌍 The exact syntax is given in Appendix A. If we follow this example through from the point of view of AS2, we would represent this policy as follows:
Example:
aut-num: AS2
as-in: from AS3 10 accept AS3 AS4
as-out: to AS3 announce AS1 AS2
interas-in:from AS3 193.0.1.1/32 193.0.1.2/32 (pref=5) accept AS3
interas-in:from AS3 193.0.1.1/32 193.0.1.2/32 (pref=9) accept AS4
interas-in:from AS3 193.0.1.5/32 193.0.1.6/32 (pref=7) accept AS4
...Here we see additional policy information between two ASs in terms of the IP addresses of the connection 🧠 The parentheses and keyword are syntactic placeholders that make the attributes easier to read. If pref=MED is specified, the preference indicated by the remote AS via the multi-exit-discriminator metric (such as BGP's) is used. Of course, this type of inter-AS policy should always be bilaterally agreed upon to avoid asymmetry, and in practice there may need to be corresponding interas-out attributes in the policy representation of AS3 💜
The interas-out attribute is similar to interas-in, the way as-out is to as-in. The one major difference is that interas-out lets you associate an outgoing metric with each route. It is important to note that this metric is just passed to the peer AS, and it is at the peer AS's discretion whether to use it or ignore it. A special value of IGP specifies that the metric passed to the receiving AS will be derived from the IGP of the sending AS. In this way the peer AS can choose the optimal link for its traffic, as determined by the sending AS ✨
If we look at the corresponding interas-out for AS3, we would see the following:
Example:
aut-num: AS3
as-in: from AS2 10 accept AS1 A2
as-out: to AS2 announce AS3 AS4
interas-out:to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=5) announce AS3
interas-out:to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=9) announce AS4interas-out:to AS2 193.0.1.6/32 193.0.1.5/32 (metric-out=7) announce AS4
...Okay bestie, the interas policies do not replace the global policy 💅 You still have to write out as-in, as-out, and the other policy attributes too 🫶 If the global policy names more routes than all the local policies combined, then local preferences for those extra routes are assumed to be equal on every link ✨
Any route that shows up in interas-in/out but not in as-in/out is assumed to be not accepted/announced between those two ASes 💀 Diagnostic tools should flag that as an error, no debate 🚩 And if you write an interas-in or interas-out line, you're also required to write the matching global line in as-in or as-out 🎀 Also, the cost in as-in has zero relationship with the preferences you use in interas-in, so don't mix them up 🙈
The interaction of interas-in/interas-out with as-in/as-out
We already defined this above, but the rules for how interas-in/out work alongside as-in/as-out are worth spelling out so nobody gets confused while implementing 🦋
Whenever you use interas-in or interas-out, the policy you describe between two ASes has to be either exactly the same as the global as-in or as-out policy, or a smaller subset of it 🌸 If it's a subset, the leftover routes are implicitly shared across all the connections 💜 Describing a superset is an error, meaning you can't announce or accept more routes than the global policy allows 😭
When you're writing complicated interas-based policies, it's a good idea to spell out everything explicitly against the global as-in and as-out policy, so there's no room for ambiguity ✨
Let's look at a simple example, only looking at inbound announcements to keep it easy 🍓 Here's the global policy:
aut-num: AS1
as-in: from AS2 10 accept AS100 OR {10.0.0.0/8}Imagine there are three peerings between AS1 and AS2, called L1-R1, L2-R2 and L3-R3 🌈 In real life, the policy is to accept AS100 equally on all three links, and to only route 10.0.0.0/8 over L3-R3 👑 The easy way to note that exception is to add an interas policy just for L3-R3:
interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8}That implicit rule, where anything not mentioned in an interas policy is accepted on all links with equal preference, gets you exactly the result you want 🔥
You could also write the exact same thing out explicitly:
interas-in: from AS2 L1 R1 (pref=100) accept AS100
interas-in: from AS2 L2 R2 (pref=100) accept AS100
interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8}This might look super obvious, but things get messy when not every connection is mentioned 😬 Say you only wrote the interas-in line for L3-R3, like this:
aut-num: AS1
as-in: from AS2 10 accept AS100 OR {10.0.0.0/8}
interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8}By the rules above, the other links would be equal to the global policy minus the sum of the local policies, which works out to ((AS100 OR {10.0.0.0/0}) / (AS100 OR {10.0.0.0/0})) = empty. That means nothing gets accepted on L1-R1 and L2-R2, and that is wrong 💀
Another one: say you only registered the policy for link L2-R2:
interas-in: from AS2 L2 R2 (pref=100) accept AS100Then the implicit policy for both L1-R1 and L3-R3 comes out as:
interas-in: from AS2 L1 R1 (pref=100) accept {10.0.0.0/8}
interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8}That's worked out as the global policies minus the interas-in policies you did register (just accept AS100, since that was the L2-R2 line), with equal cost for the remaining connections. Again, clearly not what anyone meant 🙈
We strongly recommend that you always mention every policy for every interas connection explicitly, so you dodge these errors 💖 Always make sure the interas policies add up to the global policy. And if the interas policies differ in really complicated ways, it's worth thinking about splitting the AS into separate ASes 🧚 That's beyond the direct scope of this document though, so we're leaving it there 🫶
Also, just to be clear, there is no direct relationship between the cost used in as-in and the preference used in interas-in ✨
How to describe the exclusion policy of a certain AS - "as-exclude"
Some ASes have a routing policy where certain routes get excluded if a particular AS is being used as transit 🦋 Honestly, this isn't great practice in general, because it makes implicit assumptions about the topology, and asymmetry can easily happen if nobody coordinates 😬 But it still needs a home inside the routing policy representation, so here we are 💅
This is done with the "as-exclude" attribute 💜 The exact syntax lives in Appendix A, next to the rest of the defined syntax for the "aut-num" object. Still, a little explanation helps. Here's an example topology:
Example:
AS4--------AS3
| | |
| | |
AS1--------AS2--------AS5And here's a simple policy to go with it:
Example:
aut-num: AS1
as-in: from AS2 100 accept ANY
as-out: to AS2 announce AS1
as-exclude: exclude AS4 to ANY
....This is a spicy policy 🌶️ In simple terms, it says AS1 doesn't want to reach anything if the path transits AS4 🙅♀️ That can totally be a valid policy! But here's the tea: if AS2 decides for whatever reason to route to AS3 via AS4, then AS1 instantly has no connectivity to AS3 💀 Or, if AS1 is running default to AS2, packets from AS1 will still flow via AS4 anyway 😭 The big takeaway is that AS1 can tell its neighbors about its policy, but it has no direct control over how that policy gets enforced upstream 🫠
Here's another wild scenario showing the unexpected results of an "as-exclude" policy 👀 Let's say that in the example above, AS2 prefers AS4 to reach AS3, and AS1 doesn't use default routing. Then, as we said, AS1 has no connectivity to AS3. Now suppose the link between AS2 and AS4 goes down for some reason. Like so:
Example:
AS4--------AS3
|
|
AS1--------AS2--------AS5Suddenly AS1 has connectivity to AS3 again 🤯 That unexpected behavior is something to keep in mind when you create policies based on the "as-exclude" attribute ✨
The second problem with this kind of policy is the risk of asymmetry 🌀 In the original example, we saw the correct policy from AS1's point of view. But if ASes that have connectivity through AS4 don't use a similar policy, you end up with asymmetric traffic and policy 😵 If an AS does use this kind of policy, it has to understand the consequences: the specified routes that transit the AS in question (meaning routing announcements with that AS in the AS path information) will get excluded 🚫 If nobody coordinates, this can easily cause asymmetry, or even worse, loss of connectivity to unknown ASes sitting behind (or in front of, for that matter) the transit AS 😱 With all that in mind, this attribute can only be treated as advice to other service providers 🫶 That said, it doesn't stop you from using it with policy-based tools if the attribute exists 💅
Finally, by being able to use a route keyword based on any of the four notations given in the syntax, the receiving AS can say exactly which routes it wants to exclude through a given transit AS, all the way down to network granularity 🎀
7. AS Macros ✨
Keeping track of every single new AS in the routing registry is a lot 😩 A handy shortcut is to define an `AS Macro' 🧺 which is basically a convenient way to group ASes together 💜 That way, every AS guardian doesn't have to add each new AS into its routing policy, as described by the as-in and as-out attributes of its AS object 🦋
Heads up though: using AS Macros creates an implicit trust in whoever is the guardian of that AS-Macro 🫣
An AS-Macro can be used inside <routing policy expressions> for the "as-in" and "as-out" attributes in the aut-num object 🌸 The AS-Macro object is then used to derive the list or group of ASes 🧚
Here's a simple example:
Example:
aut-num: AS786
as-in: from AS1755 100 accept AS-EBONE AND NOT AS1104
as-out to AS1755 announce AS786
.....And here's the as-macro object for AS-EBONE:
as-macro: AS-EBONE
descr: ASes routed by EBONE
as-list: AS2121 AS1104 AS2600 AS2122
as-list: AS1103 AS1755 AS2043
guardian: guardian@ebone.net
......So the policy gets evaluated to:
aut-num: AS786
as-in: from AS1755 100 accept (AS2121 OR AS1104 OR AS2600 OR AS2122
as-in: from AS1755 100 accept AS1103 OR AS1755 OR
as-in: from AS1755 100 accept AS2043) AND NOT AS1104
......Note that the examples above use the line-wrapping rule from Appendix A for policy lines 🎀 For the AS-Macro syntax itself, check out Appendix C 💖
8. The Community Object ✨
okay so a community is basically a group of routes that can't be represented as one AS or a group of ASes 🧚 but it's still super useful to bundle routes that have something in common 💅 like a special access policy to a supercomputer centre, a group of routes used for one specific mission, or a discipline whose institutes are scattered across a bunch of autonomous systems 🎀. communities can also group routes for network statistics 📊 (iykyk, stats are everything)
communities don't exchange routing information since they aren't an autonomous system 🙈 they don't define routing policies, they define access or usage policies. BUT they can be used together with an AS's routing policy to define a set of routes that the AS sets its routing policy for 🫶
communities should be defined in a strict way so we don't end up making as many communities as there are routes (or even worse 💀). there are two rules to follow:
- Communities must have a global meaning. Communities that have no global meaning are only used in a local environment and should be avoided. 🌸
- Communities must not be defined to express non-local policies. It should be avoided that a community is created because some other organization forces a policy upon your organization. Communities must only be defined to express a policy defined by your organization. 🛑
Community examples
there are some clear examples of communities ✨
- BACKBONE - all customers of a given backbone service provider, even though they can have various different routing policies and hence belong to different ASes. this would be extremely useful for statistics collection 📈
- HEPNET - the High Energy Physics community partly shares infrastructure with other organizations, and the institutes it consists of are scattered all over Europe, often being part of a non HEPNET autonomous system. to allow statistics, access or part of a routing policy, a community HEPNET, consisting of all routes that are part of HEPNET, conveniently groups all these routes 🔬
- NSFNET - the National Science Foundation Network imposes an acceptable use policy on routes that wish to make use of it. a community NSFNET could imply the set of routes that comply with this policy 🇺🇸
- MULTI - a large multinational corporation that doesn't have its own internal infrastructure, but connects the various parts of its organization by using local service providers that connect them all together, may decide to define a community to restrict access to its networks, so only networks that are part of this community get in. this way a corporate network can be defined on shared infrastructure. this community could also be used by any of the service providers to do statistics for the whole corporation, for instance for topology or bandwidth planning 🏢💜
similar to autonomous systems, each community is represented in the RIPE database by both a community object and community tags on the route objects representing the routes that belong to the community. the community object stores descriptive, administrative and contact information about the community 📇
the community tags on the route objects define the set of routes belonging to a community. a route can have multiple community tags. the community tags can only be created and updated by the "guardian" of the community and not by those directly responsible for the particular network. this makes sure community guardians stay in control of community membership 👑
here's how this might look in terms of the community tags within the network object 🧾 we have an example where the route 192.16.199.0/24 has a single routing policy (i.e. that of AS 1104), but is part of several different communities of interest. we use the tag comm-list to represent the list of communities associated with this route. NIKHEF-H uses the service provider SURFNET (a service provider with customers with more than one routing policy), is also part of the High Energy Physics community, and has the ability to access the Supercomputer at CERN (the community CERN-SUPER is somewhat national, but is meant as an example of a possible use of an access policy constraint) 🌈
Example:
route: 192.16.199.0/24
descr: Local Ethernet
descr: NIKHEF section H
origin: AS1104
comm-list: HEPNET CERN-SUPER SURFNET
changed: ripe-dbm@ripe.net 920604
source: RIPEin the examples above some communities have been defined. the community object itself takes the following format 💖
Example:
community: SURFNET
descr: Dutch academic research network
authority: SURFnet B.V.
guardian: comm-guardian@surfnet.nl
admin-c: Erik-Jan Bos
tech-c: Erik-Jan Bos
changed: ripe-dbm@ripe.net 920604
source: RIPEfor a complete explanation of the syntax, check out Appendix B 📖
9. Representation of Routing Policies 🦋
routing policies of an AS are represented in the autonomous system object. we'll start with some examples so you get the hang of how routing information is represented, used and derived 🧠 for the full syntax of the "aut-num" object, see Appendix A.
the topology of routing exchanges is represented by listing how routing information is exchanged with each neighboring AS. this is done separately for incoming and outgoing routing information. to provide backup and back door paths, a relative cost is associated with incoming routing information 🔁
Example 1:
AS1------AS2this shows a simple routing exchange between two presumably isolated ASes. even if either of them has routing information about routes in ASes other than AS1 and AS2, none of that gets announced to the other 🙅♀️
aut-num: AS1
as-out: to AS2 announce AS1
as-in: from AS2 100 accept AS2
aut-num: AS2
as-out: to AS1 announce AS2
as-in: from AS1 100 accept AS1the number 100 in the in-bound specifications is a relative cost, which is used for backup and back door routes. the absolute value doesn't mean anything. what matters is the relation between different values within the same AS object. a lower value means a lower cost. this is intentionally similar to the cost-based preference scheme used with DNS MX RRs 💅
Example 2:
now suppose AS2 is connected to one more AS, besides AS1, and let's call that AS3:
AS1------AS2------AS3in this case there are two reasonable routing policies:
- a) AS2 just wants to exchange traffic with both AS1 and AS3 itself, without passing traffic between AS1 and AS3.
- b) AS2 is willing to pass traffic between AS3 and AS1, thus acting as a transit AS. 🚦
Example 2a:
in the first case, AS1's representation in the routing registry stays unchanged, and so does the part of AS2's representation that describes the routing exchange with AS1. a description of the additional routing exchange with AS3 gets added to AS2's representation 📝
aut-num: AS1
as-out: to AS2 announce AS1
as-in: from AS2 100 accept AS2
aut-num: AS2
as-out: to AS1 announce AS2
as-in: from AS1 100 accept AS1
as-out: to AS3 announce AS2
as-in: from AS3 100 accept AS3
aut-num: AS3
as-out: to AS2 announce AS3
as-in: from AS2 100 accept AS2note that in this example, AS2 keeps full control over its resources 👑 even if AS3 and AS1 were to allow each other's routes in from AS2, the routing information wouldn't flow, because AS2 isn't announcing it. of course AS1 and AS3 could just send traffic to each other via AS2 even without AS2 announcing the routes, hoping that AS2 forwards it correctly. but questionable practices like that are beyond the scope of this document 🙃
Example 2b:
if, unlike the previous case, AS1 and AS3 are supposed to have connectivity to each other via AS2, then all the AS objects have to change 🔄
aut-num: AS1
as-out: to AS2 announce AS1
as-in: from AS2 100 accept AS2 AS3
aut-num: AS2
as-out: to AS1 announce AS2 AS3
as-in: from AS1 100 accept AS1
as-out: to AS3 announce AS2 AS1
as-in: from AS3 100 accept AS3
aut-num: AS3
as-out: to AS2 announce AS3
as-in: from AS2 100 accept AS1 AS2note that the amount of routing information exchanged with a neighbor AS is defined in terms of routes belonging to ASes. in BGP terms, this is the AS where the routing information originates, and the originating AS information carried in BGP could be used to implement the desired policy. however, using BGP or the BGP AS-path information is not required to implement the policies specified this way. configurations based on route lists can easily be generated from the database. the AS path information provided by BGP can then be used as an additional checking tool, if desired 🛠️
the specification understands one special expression, which can be written as a boolean expression 🎯
ANY- means any routing information known. For output, this means that all routes an AS knows about are announced. For input, it means that anything is accepted from the neighbor AS. 🌍
Example 3:
AS4 is a stub customer AS that only talks to service provider AS123 🏠
|
|
-----AS123------AS4
|
|aut-num: AS4
as-out: to AS123 announce AS4
as-in: from AS123 100 accept ANY
aut-num: AS123
as-in: from AS4 100 accept AS4
as-out: to AS4 announce ANY
<further neighbors>since AS4 has no other way to reach the outside world than AS123, it isn't strictly necessary for AS123 to send routing information to AS4. AS4 can simply send all traffic for which it has no explicit routing information to AS123 by default. this strategy is called default routing 🧭 it's expressed in the routing registry by adding one or more default tags to the autonomous system that uses this strategy. in the example above, that would look like this:
aut-num: AS4
as-out: to AS123 announce AS4
default: AS123 100
aut-num: AS123
as-in: from AS4 100 accept AS4
<further neighbors>Example 4:
AS4 now connects to a different operator, AS5. AS5 uses AS123 for outside connectivity, but has no direct connection to AS123 itself. so AS5's traffic to and from AS123 has to pass through AS4, and AS4 agrees to act as a transit AS for this traffic 🚌
|
|
-----AS123------AS4-------AS5
|
|aut-num: AS4
as-out: to AS123 announce AS4 AS5
as-in: from AS123 100 accept ANY
as-out: to AS5 announce ANY
as-in: from AS5 50 accept AS5
aut-num: AS5
as-in: from AS4 100 accept ANY
as-out: to AS4 announce AS5
aut-num: AS123
as-in: from AS4 100 accept AS4 AS5
as-out: to AS4 announce ANY
<further neighbors>Now AS4 has two sources of external routing info 👀. There's AS5, which only tells it about AS5's own routes, and there's AS123, which tells it about the external world 🌍. ngl this part is kinda interesting: AS4 accepts info about AS5 from both AS123 and AS5, even though AS5 info can't actually come from AS123, because AS5 is only connected via AS4 itself 🤔. The cost of 50 from AS5 itself is lower than the 100 from AS123, so AS5 is still believed even if AS123 unexpectedly announces AS5 💅.
Default routing works for AS5 here too, kinda like the last example 🧚. AS4 can also use default routing towards AS123:
aut-num: AS4
as-out: to AS123 announce AS4 AS5
default: AS123 11
as-in: from AS5 50 accept AS5No announcements to AS5 needed, they just default to us 🫶
aut-num: AS5
as-out: to AS4 announce AS5
default: AS4 100
aut-num: AS123
as-in: from AS4 100 announce AS4 AS5
<further neighbors>Okay so the cost on default routing is totally separate from the cost on inbound announcements 💖. The default route will never be taken if an explicit route is known to the destination, so an explicit route can never have a higher cost than the default route. The cost on the default route is only useful when you want to configure multiple default routes for redundancy ✨.
Also, in this example the default-route setup behaves a little differently than the explicit-route one 👀. If the AS4-AS5 link fails, AS4 will send traffic to AS5 to AS123 when using the default configuration. Normally this doesn't make much difference, since there's no answer and therefore little traffic. But with certain datagram applications that don't require acknowledgments, significant amounts of traffic may be uselessly directed at AS123 😭. Similarly, default routing should not be used if there are stringent security policies which prescribe that any traffic intended for AS5 never touches AS123 🔒.
Once things get more complex, default routes can lead to unexpected results or even defeat the routing policies established when links fail 💀. As an example, consider how Example 5a) below could be implemented using default routing. Therefore, generally it can be said that default routing should only be used in very simple topologies 🌸.
Example 5:
In a different example, AS4 has a private connection to AS6, which in turn is connected to the service provider AS123 🎀:
|
|
-----AS123------AS4
| |
| |
| |
AS6 ---------+There are a number of policies worth examining in this case 👑:
a) AS4 and AS6 wish to exchange traffic between themselves exclusively via the private link between themselves. Such traffic should never pass through the backbone (AS123). The link should never be used for transit traffic, i.e. traffic not both originating in and destined for AS4 and AS6.
b) AS4 and AS6 wish to exchange traffic between themselves via the private link between themselves. Should the link fail, traffic between AS4 and AS6 should be routed via AS123. The link should never be used for transit traffic.
c) AS4 and AS6 wish to exchange traffic between themselves via the private link between themselves. Should the link fail, traffic between AS4 and AS6 should be routed via AS123. Should the connection between AS4 and AS123 fail, traffic from AS4 to destinations behind AS123 can pass through the private link and AS6's connection to AS123.
d) AS4 and AS6 wish to exchange traffic between themselves via the private link between themselves. Should the link fail, traffic between AS4 and AS6 should be routed via AS123. Should the backbone connection of either AS4 or AS6 fail, the traffic of the disconnected AS should flow via the other AS's backbone connection.
Example 5a:
aut-num: AS4
as-in: from AS123 100 accept NOT AS6
as-out: to AS123 announce AS4
as-in: from AS6 50 accept AS6
as-out: to AS6 announce AS4
aut-num: AS123
as-in: from AS4 100 accept AS4
as-out: to AS4 announce ANY
as-in: from AS6 100 accept AS6
as-out: to AS6 announce ANY
<further neighbors>
aut-num: AS6
as-in: from AS123 100 accept NOT AS4
as-out: to AS123 announce AS6
as-in: from AS4 50 accept AS4
as-out: to AS4 announce AS6Note that the config here is slightly inconsistent 🙈. AS123 will announce AS6 to AS4 and AS4 to AS6. These announcements get filtered out on the receiving end, which still implements the desired policy. Consistency checking tools might flag these cases however.
Example 5b:
aut-num: AS4
as-in: from AS123 100 accept ANY
as-out: to AS123 announce AS4
as-in: from AS6 50 accept AS6
as-out: AS6 AS4
aut-num: AS123
as-in: AS4 100 AS4
as-out: AS4 ANY
as-in: AS6 100 AS6
as-out: AS6 ANY
<further neighbors>
aut-num: AS6
as-in: from AS123 100 accept ANY
as-out: to AS123 announce AS6
as-in: from AS4 50 accept AS4
as-out: to AS4 announce AS6The thing to note here is that in the ideal operational case, 'all links working', AS4 will receive announcements for AS6 from both AS123 and AS6 itself ✨. In this case the announcement from AS6 is preferred because of its lower cost, so the private link gets used as desired 🦋. AS6 is configured as a mirror image.
Example 5c:
The new feature here is that should the connection between AS4 and AS123 fail, traffic from AS4 to destinations behind AS123 can pass through the private link and AS6's connection to AS123 🧚.
aut-num: AS4
as-in: from AS123 100 accept ANY
as-out: to AS123 announce AS4
as-in: from AS6 50 accept AS6
as-in: from AS6 110 accept ANY
as-out: to AS6 AS4
aut-num: AS123
as-in: from AS4 1 accept AS4
as-out: to AS4 announce ANY
as-in: from AS6 1 accept AS6
as-in: from AS6 2 accept AS4
as-out: to AS6 announce ANY
<further neighbors>
aut-num: AS6
as-in: from AS123 100 accept ANY
as-out: to AS123 AS6 announce AS4
as-in: from AS4 50 accept AS4
as-out: to AS4 announce ANYIt's important to make sure you propagate routing information for both directions in backup situations like this 🫶. Connectivity in just one direction is not useful at all for almost all applications 😭.
Also, if the AS6-AS123 connection breaks, AS6 will only be able to talk to AS4 💅. The symmetrical case (5d) is left as an exercise to the reader 📝.
10. Future Extensions 🦋
We envision that over time the requirements for describing routing policy will evolve 🌈. The routing protocols will evolve to support the requirements, and the routing policy description syntax will need to evolve as well. For that purpose, a separate document will describe experimental syntax definitions for policy description. This document [14] will be updated when new objects or attributes are proposed or modified ✨.
11. References 📚
[1] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P., Terpstra, M., "Representation of IP Routing Policies in the RIPE Database", RIPE-81, February 1993.
[2] Merit Network Inc.,"Representation of Complex Routing Policies of an Autonomous System", Work in Progress, March 1994.
[3] PRIDE Tools Release 1. See ftp.ripe.net:pride/tools/pride-tools-1.tar.Z.
[4] Merit Inc. RRDB Tools. See rrdb.merit.edu:pub/meritrr/*
[5] The Network List Compiler. See dxcoms.cern.ch:pub/ripe-routing-wg/nlc-2.2d.tar
[6] Lord, A., Terpstra, M., "RIPE Database Template for Networks and Persons", RIPE-119, October 1994.
[7] Karrenberg, D., "RIPE Database Template for Domains", RIPE-49, April 1992.
[8] Lougheed, K., Rekhter, Y., "A Border Gateway Protocol 3 (BGP-3)", RFC1267, October 1991.
[9] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC-1654, May 1994.
[10] Bates, T., Karrenberg, D., Terpstra, M., "Support for Classless Internet Addresses in the RIPE Database", RIPE-121, October 1994.
[11] Karrenberg, D., "Authorisation and Notification of Changes in the RIPE Database", RIPE-120, October 1994.
[12] Bates, T., "Support of Guarded fields within the RIPE Database", ripe-117, July 1994.
[13] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., Zappala, D., "Source Demand Routing: Packet Format and Forwarding Specification (Version 1)", Work in Progress, March 1994.
[14] Joncheray, L., "Experimental Objects and attributes for the Routing Registry", RIPE-182, October1994.
[15] Bates, T., "Specifying an `Internet Router' in the Routing Registry", RIPE-122, October 1994.
[16] Bates, T., Karrenberg, D., Terpstra, M., "RIPE Database Transition Plan", RIPE-123, October 1994.
12. Security Considerations 🔒
Security issues are beyond the scope of this memo 💀.
13. Authors' Addresses 💖
Tony Bates
MCI Telecommunications Corporation
2100 Reston Parkway
Reston, VA 22094
USA
+1 703 715 7521
Tony.Bates@mci.net
Elise Gerich
The University of Michigan
Merit Computer Network
1075 Beal Avenue
Ann Arbor, MI 48109
USA
+1 313 936 2120
epg@merit.edu
Laurent Joncheray
The University of Michigan
Merit Computer Network
1075 Beal Avenue
Ann Arbor, MI 48109
USA
+1 313 936 2065
lpj@merit.edu
Jean-Michel Jouanigot
CERN, European Laboratory for Particle Physics
CH-1211 Geneva 23
Switzerland
+41 22 767 4417
Jean-Michel.Jouanigot@cern.ch
Daniel Karrenberg
RIPE Network Coordination Centre
Kruislaan 409
NL-1098 SJ Amsterdam
The Netherlands
+31 20 592 5065
D.Karrenberg@ripe.net
Marten Terpstra
Bay Networks, Inc.
2 Federal St
Billerica, MA 01821
USA
+1 508 436 8036
marten@BayNetworks.com
Jessica Yu
The University of Michigan
Merit Computer Network
1075 Beal Avenue
Ann Arbor, MI 48109
USA
+1 313 936 2655
jyy@merit.eduAppendix A - Syntax for the aut-num object. ✨
Okay, this is the cheat sheet 🎀 It lists every tag on the aut-num object, whether each one is mandatory or optional, and whether it can show up once [single] or more than once [multiple]. If an attribute spans several lines, you have to repeat the attribute name on every line. See [6] for the descr: example, bestie.
aut-num: [mandatory] [single]
as-name: [optional] [single]
descr: [mandatory] [multiple]
as-in: [optional] [multiple]
as-out: [optional] [multiple]
interas-in: [optional] [multiple]
interas-out: [optional] [multiple]
as-exclude: [optional] [multiple]
default: [optional] [multiple]
tech-c: [mandatory] [multiple]
admin-c: [mandatory] [multiple]
guardian: [mandatory] [single]
remarks: [optional] [multiple]
notify: [optional] [multiple]
mnt-by: [optional] [multiple]
changed: [mandatory] [multiple]
source: [mandatory] [single]Each attribute has its own syntax, so let's go through them one by one 💅
aut-num:
This is the autonomous system number. It must be a uniquely allocated AS number from an AS registry (think the RIPE NCC, the Inter-NIC, etc.) 🌸
Format:
AS<positive integer between 1 and 65535>Example:
aut-num: AS1104Status: mandatory, only one line allowed 🔥
as-name:
This is the name for the AS. It should be as short but as informative as possible, which is honestly a vibe check 🧚
Format: text made of capitals, dashes ("-") and digits, but it must start with a capital.
Example:
as-name: NIKHEF-HStatus: single, only one line allowed
descr:
A short description of the Autonomous System ✨
Format: free text
Example:
descr: NIKHEF section H
descr: Science Park Watergraafsmeer
descr: AmsterdamStatus: mandatory, multiple lines allowed 🦋
as-in:
This is how you describe the routing information you accept from your AS peers. It's giving policy, bestie 👑
Format:
from <aut-num> <cost> accept <routing policy expression>The keywords from and accept are optional and can be omitted 🫶
<aut-num> refers to your AS neighbor.
<cost> is a positive integer that expresses the relative cost of the routes you learn. The lower the cost, the more preferred the route. Lowkey simple, but it matters a lot 💜
The <routing policy expression> can take the following formats:
- A list of one or more ASes, AS Macros, Communities or Route Lists.
A Route List is a list of routes in prefix length format, separated by commas, and surrounded by curly brackets (braces, i.e. { and }).
Examples:
as-in: from AS1103 100 accept AS1103
as-in: from AS786 105 accept AS1103
as-in: from AS786 10 accept AS786 HEPNET
as-in: from AS1755 110 accept AS1103 AS786
as-in: from AS3333 100 accept {192.87.45.0/16}- A set of KEYWORDS. Right now there's one KEYWORD defined:
ANY: this means anything the neighbor AS knows. Main character energy 🌈
- A logical expression built from either 1 or 2 above. The current logical operators are:
- AND
- OR
- NOT
These operators are defined as true BOOLEAN operators, even if the operands don't look BOOLEAN at all. Here's how they work 🎀
Operator Operation Example
OR UNION AS1 OR AS2
|
+-> all routes in AS1
or AS2.
AND INTERSECTION AS1 AND HEPNET
|
+-> a route in AS1 and
belonging to
community HEPNET.
NOT COMPLEMENT NOT AS3
|
+-> any route except
AS3 routes.Rules get grouped together using parentheses, i.e. ( and ).
The order in which operators get evaluated, and how they associate, goes like this 🍓
Operator Associativity
() left to right
NOT right to left
AND left to right
OR left to rightNOTE: if there's no logical operator between ASes, AS-macros, Communities, Route Lists and KEYWORDS, it's implicitly evaluated as an OR operation. The OR can be left out for conciseness. BUT the operators are still evaluated in the order above, so make sure you include parentheses whenever you need them. Here's a simple example. Say your policy is: from AS1755, I accept all routes except routes from AS1, A2 and AS3, and you enter the following as-in line:
as-in: from AS1755 100 accept NOT AS1 AS2 AS3This gets evaluated as:
as-in: from AS1755 100 accept NOT AS1 OR AS2 OR AS3Which in turn gets evaluated like this:
(NOT AS1) OR AS2 OR AS3
-> ((ANY except AS1) union AS2) union AS3)
--> (ANY except AS1)This is clearly incorrect and not what you wanted, bestie 🙈 The correct syntax is:
as-in: from AS1755 100 accept NOT (AS1 AS2 AS3)Producing the following evaluation:
NOT (AS1 OR AS2 OR AS3)
-> (ANY) except (union of AS1, AS2, AS3)Which depicts the routing policy you actually wanted. It can also be written like this, which is maybe a bit clearer:
as-in: from AS1755 100 accept ANY AND NOT
as-in: from AS1755 100 accept (AS1 OR AS2 OR AS3)Examples:
as-in: from AS1755 100 accept ANY AND NOT (AS1234 OR AS513)
as-in: from AS1755 150 accept AS1234 OR {35.0.0.0/8}A rule can be wrapped over lines, as long as the associated <aut-num>, <cost> values and the from and accept keywords are repeated and sit on consecutive lines. 💖
Example:
as-in: from AS1755 100 accept ANY AND NOT (AS1234 AS513)and
as-in: from AS1755 100 accept ANY AND NOT (
as-in: from AS1755 100 accept AS1234 AS513)are evaluated to the same result. Please note that the ordering of these continuing lines is significant 🦋
Status: optional, multiple lines allowed
as-out:
This is the generated routing information you send to your other AS peers 📣
Format:
to <aut-num> announce <routing policy expressionThe to and announce keywords are optional and can be omitted.
<aut-num> refers to your AS neighbor.
The <routing policy expression> is explained in the as-in attribute definition above ✨
Example:
as-out: to AS1104 announce AS978
as-out: to AS1755 announce ANY
as-out: to AS786 announce ANY AND NOT (AS978)Status: optional, multiple lines allowed
interas-in:
This describes the incoming local preferences on an inter AS connection. It's the detail-oriented one, iykyk 🧚
Format:
from <aut-num> <local-rid> <neighbor-rid> <preference> accept
<routing policy expression>The keywords from and accept are optional and can be omitted.
<aut-num> is an autonomous system as defined in as-in.
<local-rid> contains the IP address of the border router in the AS that describes the policy. The IP address must be in prefix length format.
<neighbor-rid> contains the IP address of the neighbor AS's border router, the one this AS accepts routes from as defined in the <routing policy expression>. IP addresses must be in prefix length format.
<preference> is defined as follows:
(<pref-type>=<value>)It should be noted that the parentheses ( and ) and the <pref-type> keyword must be present for this preference to be valid. No skipping the brackets, periodt 🙅♀️
<pref-type> currently only supports "pref". It could be expanded to other types of preference, such as TOS/QOS, as routing technology matures 🌸
<value> can take one of the following values:
<cost>: this is a positive integer that expresses the relative cost of the routes learned. The lower the cost, the more preferred the route. This <cost> value is only comparable to other interas-in attributes, not to as-in attributes.
MED: this indicates the AS will use the MUTLI_EXIT_DISCRIMINATOR (MED) metric, as implemented in BGP4 and IDRP, sent from its neighbor AS.
NOTE: Combinations of MED and <cost> should be avoided for the same destinations.
CAVEAT: The pref-type values may well be enhanced in the future as more inter-AS routing protocols introduce other metrics.
Any route specified in interas-in and not specified in as-in is assumed to be not accepted between the ASes concerned. Diagnostic tools should flag this inconsistency as an error 🚩 It should also be noted that if an interas-in policy is specified, then it is mandatory to specify the corresponding global policy in the as-in line. Please note there's no relevance between the cost associated with as-in and the preferences used in interas-in 💅
<routing policy expression> is an expression as defined in as-in above.
Examples:
NB: This line is wrapped for readability.
interas-in: from AS1104 192.(pref=10)/accept.AS786.AS987
interas-in: from AS1104 192.87.45.(pref=20)2accept.AS987
interas-in: from AS1103 192.87.45.2(pref=MED)8accept2ANYStatus: optional, multiple lines allowed 🎀
interas-out:
Okay so this one is the outbound mirror of interas-in 💅 It's the "here's what I'm sending you" attribute, and it's giving precision 🦋
Format:
to <aut-num> <local-rid> <neighbor-rid> [<metric>] announce
<routing policy expression>The keywords to and announce are optional and can be omitted 🫶
The definitions of <aut-num>, <local-rid> <neighbor-rid>, and <routing policy expression> are identical to the ones in interas-in, so no need to re-explain 🌸
<metric> is optional and looks like this:
(<metric-type>=<value>)Quick heads-up: the parentheses ( and ) and the keyword <metric-type> must be present for this metric to be valid 🙈
<metric-type> currently only supports metric-out. It could expand to other kinds of preference, like TOS/QOS, as routing tech matures 🔥
<value> can take one of the following:
<num-metric>: a pre-configured metric for outbound routes. The lower the cost, the more preferred the route 👑 This value gets literally passed along by the routing protocol to the neighbor. It's expected to be used there, which is indicated bypref=MEDon the corresponding interas-in attribute. Whether the neighbor AS accepts your outgoing metric is totally up to them 💀IGP: this means the metric reflects the AS's internal topology cost. The topology gets reflected here by using MED, which is derived from the AS's IGP metric ✨
NOTE: combinations ofIGPand<num-metric>should be avoided for the same destinations. Don't mix them, bestie 🚫
CAVEAT: the metric-out values may well be enhanced in the future as more interas protocols make use of metrics 🌈
Any route specified in interas-out and not specified in as-out is assumed not announced between the ASes concerned. Diagnostic tools should flag this inconsistency as an error 🚩 Also, if an interas-out policy is specified, it is mandatory to specify the corresponding global policy in the as-out line 💜
Examples:
interas-out:ntoiAS1104p192.87.45.254/32t192.87.45.80/32
interas-out: to AS1104m192.87.45.254/32n192.87.45.80/32
interas-out: to AS1103 192.87.45.254/325192.87.45.80/32
(metric-out=IGP) announce ANYStatus: optional, multiple lines allowed
as-exclude:
A list of transit ASes you want to ghost. Every route from them gets ignored 👻
Format:
exclude <aut-num> to <exclude-route-keyword>The keywords exclude and to are optional and can again be omitted 🎀 <aut-num> refers to the transit AS in question.
An <exclude-route-keyword> can be ONE of the following:
<aut-num>- AS macro
- Community
- ANY
Examples:
as-exclude: exclude AS690 to HEPNETThis means exclude any HEPNET routes which have a route via AS690 🧚
as-exclude: exclude AS1800 to AS-EUNETThis means exclude any AS-EUNET routes which have a route via AS1800 🌸
as-exclude: exclude AS1755 to AS1104This means exclude any AS1104 route which have a route via AS1755 🦋
as-exclude: exclude AS1104 to ANYThis means exclude all routes which have a route via AS1104. Total blackout, iconic 💀
Status: optional, multiple lines allowed
default:
An indication of how default routing is done. This is how you figure out your default route 🧭
Format:
<aut-num> <relative cost> <default-expression>Here <aut-num> is the AS peer you will default route to. <relative cost> is a positive integer used to express a preference for default. It has no relationship to the cost used in the as-in tag. The AS peer with the lowest cost is used for default over the ones with higher costs 💖
<default-expression> is optional and provides information on how a default route is selected. It can take the following formats:
- static. This indicates that a default is statically configured to this AS peer.
- A route list with the syntax described in the as-in attribute. This indicates that this list of routes is used to generate a default route. A special but valid value here is the special route some routing protocols use to indicate default:
0.0.0.0/0 - default. This is the same as
{0.0.0.0/0}. It means the routing protocol between these two peers generates a true default 👑
Examples:
default: AS1755 10
default: AS786 5 {140.222.0.0/16, 192.87.45.0/24}
default: AS2043 15 defaultStatus: optional, multiple lines allowed
tech-c:
Full name or uniquely assigned NIC-handle of a technical contact person. This is someone to contact for technical problems, such as misconfiguration 🛠️
Format:
<firstname> <initials> <lastname> or <nic-handle>Example:
tech-c: John E Doe
tech-c: JED31Status: 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: JTB1Status: mandatory, multiple lines allowed
guardian:
Mailbox of the guardian of the Autonomous System 📬
Format:
<email-address>The <email-address> should be in RFC822 domain format wherever possible 💅
Example:
guardian: as1104-guardian@nikhef.nlStatus: mandatory, only one line and e-mail address allowed
remarks:
Remarks and comments, to be used only for clarification 💬
Format:
free textExamples:
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 sent. See also [11] 🔔
Format:
<email-address>The <email-address> should be in RFC822 domain syntax wherever possible 🌈
Example:
notify: Marten.Terpstra@ripe.netStatus: 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-DBMStatus: optional, multiple lines allowed
changed:
Who changed this object last, and when that change was made 🕰️
Format:
<email-address> YYMMDDThe <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 900401Status: 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:
RIPEStatus: mandatory, only one line allowed
Appendix B - Syntax details for the community object 🎀
okay so this is the cheat sheet for community objects, bestie 💅 here's a summary of every tag, whether it's mandatory, and whether it can show up once (single) or more than once (multiple). when you're writing multiple lines for one attribute, you have to repeat the attribute name every single time. see [6] for the descr: example ✨
community: [mandatory] [single]
descr: [mandatory] [multiple]
authority: [mandatory] [single]
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]every attribute has its own little rulebook 🧚
community:
this is the name of the community, and it should be descriptive of the community it describes 🌸
Format: an upper case text string which cannot start with "AS" or any of the <routing policy expression> KEYWORDS. See Appendix A.
Example:
community: WCWStatus: mandatory, only one line allowed
descr:
a short description of the community 💖
Format: free text
Example:
descr: Science Park Watergraafsmeer
descr: AmsterdamStatus: mandatory, multiple lines allowed
authority:
the formal authority for this community, which could be an organisation, institute, committee, etc. 👑
Format: free text
Example:
authority: WCW LAN CommitteeStatus: mandatory, only one line allowed
guardian:
the mailbox of the guardian of the community 🦋
Format: <email-address>. The <email-address> should be in RFC822 domain format wherever possible.
Example:
guardian: wcw-guardian@nikhef.nlStatus: mandatory, only one line and email address allowed
tech-c:
the full name or uniquely assigned NIC-handle of a technical contact person for this community 🔥
Format: <firstname> <initials> <lastname> or <nic-handle>
Example:
tech-c: John E Doe
tech-c: JED31Status: mandatory, multiple lines allowed
admin-c:
the full name or uniquely assigned NIC-handle of an administrative contact person. in lots of cases this is the guardian's name, iykyk 😌
Format: <firstname> <initials> <lastname> or <nic-handle>
Example:
admin-c: Joe T Bloggs
admin-c: JTB1Status: mandatory, multiple lines allowed
remarks:
remarks and comments, but only for clarification, so keep it tight 🍓
Format: free text
Example:
remarks: Temporary community
remarks: Will be removed after split into ASesStatus: optional, multiple lines allowed
notify:
the notify attribute holds an email address that gets notifications whenever this object changes. see also [11] 💌
Format: <email-address>. The <email-address> should be in RFC822 domain syntax wherever possible.
Example:
notify: Marten.Terpstra@ripe.netStatus: optional, multiple lines allowed
mnt-by:
the mnt-by attribute holds a registered maintainer name. see also [11] 🧚
Format: <registered maintainer name>
Example:
mnt-by: RIPE-DBMStatus: optional, multiple lines allowed
changed:
who changed this object last, and when they did it 🕰️
Format: <email-address> YYMMDD. The <email-address> should be the address of the person who made the last change. YYMMDD is the date the change was made.
Example:
changed: johndoe@terabit-labs.nn 900401Status: mandatory, multiple lines allowed
source:
where the information came from 🌈
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 🦋
same energy as Appendix B, but for as-macro objects 💜 here's the summary of every tag, its status, and whether it's single or multiple. when a value runs over several lines, the attribute name gets repeated on each one, same as always ✨
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]here's the rulebook for each attribute 🫶
as-macro:
the name of a macro that groups at least two Autonomous Systems together, so they're easier to manage 🌸
Format: AS-<string>. The <string> should be in upper case and should not contain any special characters.
Example:
as-macro: AS-EBONEStatus: mandatory, only one line allowed
descr:
a short description of the Autonomous System Macro 💖
Format: free text
Example:
descr: Macro for EBONE connected ASesStatus: 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 the <aut-num> definition.
Example:
as-list: AS786 AS513 AS1104
as-list: AS99 AS-NORDUNETStatus: mandatory, multiple lines allowed
guardian:
the 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.netStatus: mandatory, only one line and e-mail address allowed
tech-c:
the full name or uniquely assigned NIC-handle of a technical contact person for this macro. this is who you contact for technical problems, like misconfigurations 🔧
Format: <firstname> <initials> <lastname> or <nic-handle>
Examples:
tech-c: John E Doe
tech-c: JED31Status: mandatory, multiple lines allowed
admin-c:
the full name or uniquely assigned NIC-handle of an administrative contact person. in many cases this is the guardian's name 👑
Format: <firstname> <initials> <lastname> or <nic-handle>
Examples:
admin-c: Joe T Bloggs
admin-c: JTB1Status: mandatory, multiple lines allowed
remarks:
remarks and comments, strictly for clarification 🍓
Format: free text
Example:
remarks: AS321 will be removed from this Macro shortlyStatus: optional, multiple lines allowed
notify:
an email address that gets notifications whenever this object changes. see also [11] 💌
Format: <email-address>. The <email-address> should be in RFC822 domain syntax wherever possible.
Example:
notify: Marten.Terpstra@ripe.netStatus: optional, multiple lines allowed
mnt-by:
holds a registered maintainer name. see also [11] 🧚
Format: <registered maintainer name>
Example:
mnt-by: RIPE-DBMStatus: optional, multiple lines allowed
changed:
who changed this object last, and when 🕰️
Format: <email-address> YYMMDD. The <email-address> should be the address of the person who made the last change. YYMMDD is the date the change was made.
Example:
changed: johndoe@terabit-labs.nn 900401Status: mandatory, multiple lines allowed
source:
where the information came from 🌈
this separates 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. ✨
Okay bestie, this is the cheat sheet for the route object 💅 Each row shows an attribute, whether it's mandatory or optional for the community object (yes, the original says "community object" here, so I'm keeping it 🙈), and whether it can show up [single] time or [multiple] times per object. If an attribute spans multiple lines, you have to repeat the attribute name on every line. The example for the descr: attribute is in [6] if you want to see it in action 🦋
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]Every attribute has its own syntax, so let's go through them 🎀
route:
This is the route being announced. ✨
Format: a classless representation of a route, known in the RIPE database as the "prefix length" representation. See [10] for more details on classless representations. 🧚
Examples:
route: 192.87.45.0/24This one represents the addressable bits 192.87.45.0 to 192.87.45.255.
route: 192.1.128.0/17This one represents the addressable bits 192.1.128.0 to 192.1.255.255.
Status: mandatory, only one line allowed 💖
origin:
This is the autonomous system announcing the route. 👑
Format:
<aut-num>See Appendix A for the <aut-num> syntax.
Example:
origin: AS1104Status: mandatory, only one line allowed 💖
hole:
This attribute marks the parts of the address space covered by this route object that the originator does not provide connectivity to. These holes can include routes currently being routed by another provider (like when a customer using that space has moved to a different service provider), and they can also include space that hasn't been assigned to any customer yet. 🙈
Format: a classless representation of a route, known in the RIPE database as the "prefix length" representation. See [10] for more details on classless representations. Heads up: this sub-aggregate must be a component of the one registered in the route object. 🫶
Example:
hole: 193.0.4.0/24Status: optional, multiple lines allowed 🌸
withdrawn:
This is used to say which day this route was withdrawn from the Internet routing mesh. It'll usually show up when a less specific aggregate route is now being routed, so this more specific route isn't needed anymore 😭
Format:
YYMMDDHere, YYMMDD is the date the route was withdrawn.
Example:
withdrawn: 940711Status: optional, one line allowed. 🍓
comm-list:
This is the list of one or more communities this route is part of. 🌈
Format:
<community> <community> ...See Appendix B for the <community> definition.
Example:
comm-list: HEP LEPStatus: optional, multiple lines allowed 💜
remarks:
Remarks and comments, only to be used for clarification. ✨
Format: free text
Examples:
remarks: Multihomed AS talking to AS1755 and AS786
remarks: Will soon connect to AS1104 also.Status: optional, multiple lines allowed 🦋
notify:
The notify attribute holds an email address that should get notifications whenever this object changes. See also [11]. 📬
Format:
<email-address>The <email-address> should be in RFC822 domain syntax wherever possible.
Example:
notify: Marten.Terpstra@ripe.netStatus: optional, multiple lines allowed 💅
mnt-by:
The mnt-by attribute holds a registered maintainer name. See also [11]. 🔐
Format:
<registered maintainer name>Example:
mnt-by: RIPE-DBMStatus: optional, multiple lines allowed 🌷
changed:
This tells you who changed this object last, and when the change was made. 🕰️
Format:
<email-address> YYMMDDThe <email-address> should be the address of the person who made the last change. YYMMDD is the date this change was made.
Example:
changed: johndoe@terabit-labs.nn 900401Status: mandatory, multiple lines allowed 💖
source:
This is where the information came from. 🧁
It's used to separate information from different sources kept by the same database software. For RIPE database entries, the value is fixed to RIPE.
Format:
RIPEStatus: mandatory, only one line allowed 👑
Appendix E - List of reserved words 🎀
These words are reserved for use within the attributes of the AS object. Using them is purely about clarity, and all keywords must be lower case 💅
accept
announce
exclude
from
to
transitHere's how the reserved words get used:
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: as-transit is an experimental attribute. See section 10. 🧪
Appendix F - Motivations for RIPE-81++ 🦋
This appendix explains the reasons behind the major changes in this proposal from ripe-81, so you can see the "why" 🧠
The main goals of the routing registry rework are:
- SPLIT: Separate the allocation and routing registry functions into different database objects. This makes data management easier if the Internet registry and routing registry functions get separated (like they already are in other parts of the world). It also makes it clearer what belongs to the routing registry and who has authority to change allocation versus routing data. 🍰
- CIDR: Add the ability to specify classless routes in the routing registry. Classless routes are already being used in Internet production, and aggregation information in the routing registry is necessary for network layer troubleshooting. It's also necessary because aggregation influences routing policies directly. 🌐
- CALLOC: Add the ability to allocate address space on classless boundaries in the allocation registry. This is a way to preserve address space. 🌸
- CLEAN: Clean up some of the obsolete and unused parts of the routing registry. 🧹
The major changes are 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++ 🚀
Moving from the routing registry described by ripe-81 to the one described in this document is a straightforward process, once the new registry functions have been implemented in the database software and the most commonly used registry tools understand them 🫶 The routing related attributes in the classful inetnum objects of ripe-81 can be translated straight into the new routing objects. After that, those attributes can be deleted from the inetnum object, which makes that object conform to the new schema ✨
Here are the proposed transition steps:
- Implement classless addresses and the new object definition in the database software. 🛠️
- Make common tools understand the new schema, and have them prefer it when both old and new are present. 🧰
- Invite everyone to convert their data to the new format. This can be encouraged by doing conversions automatically and proposing them to maintainers. 💌
- On 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. 🎉 The end, bestie! 🌈
📦 where this page comes from
- ietf: rfc1786 1995-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms