FreeTransit Learning Centre

Understand route objects, RPSL, AS-SETs and how operators turn routing registry data into filters.

RIPE Database, IRR and routing policy

The RIPE Database is not only a directory of number resources and contacts. It also participates in the Internet Routing Registry system, where operators describe route origins and routing policy using RPSL.

The existing FreeTransit RIPE Database object guide explains how to create the objects needed for a sponsored-resource request. This page explains why the routing objects matter and how other networks use them.

Important object types

mntner, person, role and organisation

These identify who controls an object and how operational or abuse contacts can be reached. Keep contact data current and use role accounts for functions that should survive staff changes.

aut-num

An aut-num object represents an autonomous system in the registry. It can contain routing-policy statements and references to maintainers and contacts.

route and route6

A route or route6 object states that a prefix is intended to be originated by an ASN. Operators and filter-generation tools still use these objects when building prefix filters.

An IRR route object is not a cryptographic proof. RPKI provides stronger route-origin authorisation. Maintain both because operational networks use a mixture of IRR and RPKI data.

as-set

An AS-SET groups ASNs and other AS-SETs. Transit providers and IXPs can use it to build customer-cone filters. A poorly maintained or recursive AS-SET can produce incomplete or unexpectedly large filters, so only publish relationships you understand and keep the set current.

FreeTransit policy: origin-only, without AS-SETs or downstream transit

FreeTransit accepts only routes originated directly by the applicant's own ASN. The maximum accepted AS depth is 1. We do not accept AS-SETs, customer cones, downstream ASNs or transit announcements.

This restriction applies even when an applicant has correctly learned how AS-SETs and customer-cone filtering work. FreeTransit filtering is built from an explicit list of prefixes originated by the applicant ASN, not by recursively expanding an AS-SET.

The reason is operational safety. We increasingly see structures such as AS65535:AS-ALL containing AS-UPSTREAMS, AS-DOWNSTREAMS and AS-SELF, which then include another downstream's AS-ALL. Recursive expansion can unexpectedly import unrelated upstreams, peers and further downstream networks. The resulting filter is difficult to audit and can change without FreeTransit or the applicant noticing.

FreeTransit tunnels must therefore not be used to provide transit to another ASN. Routes learned from a downstream, peer, upstream or another tunnel must never be exported over the FreeTransit session. Chaining transit tunnels through other transit tunnels creates fragile, hard-to-debug routing dependencies and is outside the purpose of the project. Applications that require downstream transit or AS-SET-based customer-cone filtering will not be accepted.

Learn the system

• RIPE NCC Academy
• RIPE NCC routing learning path
• Internet Routing Registry webinar
• RIPE NCC BGP webinar recordings
• RIPE NCC training material

See how IRR data becomes router policy

• The whois protocol for Internet routing policy — 38C3 — a modern explanation of IRR, RPSL, filter generation and the limitations of the historic whois-based system.
• NLNOG IRRexplorer — inspect IRR and observed BGP data together.
• bgpq4 — a widely used tool for generating router filters from IRR data.
• NLNOG BGP Filter Guide — practical filtering guidance and configuration examples.

What to verify before activation

• Your aut-num object exists and is maintained by the correct maintainer.
• Every announced IPv4 prefix has the intended route object.
• Every announced IPv6 prefix has the intended route6 object.
• The origin ASN in each route object is correct.
• Any AS-SETs you maintain elsewhere contain the correct members and do not depend on stale objects. FreeTransit will not use them for filtering.
• NOC and abuse contacts work and are monitored.
• The same intended origin is represented by a valid RPKI ROA.
• Your FreeTransit request contains the exact prefixes originated directly by your own ASN. No downstream or customer-cone prefixes are included.

Common misunderstandings

“A route object makes the announcement safe”

No. It documents intent and supports filtering, but it is not an end-to-end cryptographic validation mechanism.

“A ROA means I no longer need IRR objects”

Not yet. Many networks still use IRR-derived filters, sometimes together with RPKI. Publish correct data in both systems.

“My provider can infer my customer cone”

Do not rely on inference. Give providers a maintained AS-SET or an explicit prefix list, according to their onboarding process.

“The registry is paperwork that can be completed later”

Other operators may generate filters before your first announcement. Create and verify the objects before the BGP session is activated.