FreeTransit Learning Centre

Route objects, RPSL and AS-SETs, how operators turn registry data into filters, and what FreeTransit needs in your aut-num.

RIPE Database, IRR and routing policy

The RIPE Database lists number resources and contacts, and it is also part of the Internet Routing Registry (IRR). In the IRR, operators record which ASN originates which prefix and describe their routing policy in RPSL.

The FreeTransit RIPE Database object guide walks you through creating the objects for a sponsored-resource request. This page explains what the routing objects are for and how other networks use them.

Object types

`mntner`, `person`, `role` and `organisation`

These say who controls an object and how to reach the people running the network, including for abuse reports. Keep them current, and use role objects for anything that should outlive a staff change.

`aut-num`

An aut-num object represents your AS in the registry. It references maintainers and contacts and can describe your routing policy in import, export, mp-import and mp-export lines.

`route` and `route6`

A route or route6 object says that a prefix is meant to be originated by a given ASN. Many operators and filter tools still build prefix filters from these objects, and so does FreeTransit.

A route object is not cryptographic proof. RPKI ROAs are stronger, but networks use a mix of IRR and RPKI data, so publish both.

`as-set`

An AS-SET groups ASNs and other AS-SETs. Transit providers and IXPs use them to build filters for a customer and everything behind it. A stale or deeply nested AS-SET can produce filters that are incomplete or far too large, so only list relationships you understand and keep the set up to date.

FreeTransit policy: your own routes only

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

In practice, every route you send must have your ASN as both the first and the origin AS. You may prepend your own ASN; no other ASN may appear in the path.

We build your prefix filter from the route and route6 objects whose origin is your ASN, taken from the RIR databases and RADB. We don't expand AS-SETs, even correct ones.

The reason is safety. We keep seeing structures like AS65535:AS-ALL that include AS-UPSTREAMS, AS-DOWNSTREAMS and AS-SELF, where the downstream set includes another network's AS-ALL. Expanding that recursively can pull in unrelated upstreams, peers and their customers. Nobody can review such a filter properly, and it can change without you or us noticing.

So a FreeTransit tunnel must not carry transit for another ASN. Never export routes learned from a downstream, peer, upstream or another tunnel over the FreeTransit session. Chaining transit tunnels through other transit tunnels builds fragile dependencies that are hard to debug, and it's not what the project is for. We don't accept requests that need downstream transit or AS-SET-based filtering. Ordinary bilateral peering on your side is fine.

What FreeTransit needs in your aut-num

We check your aut-num for direct policy lines naming AS41051: an import from AS41051 and an export to AS41051. A reference to an AS-SET alone doesn't pass the check. For an ASN that originates its own prefixes only, this is enough:

import:     from AS41051 accept ANY
export:     to AS41051 announce AS64512
mp-import:  afi ipv6.unicast from AS41051 accept ANY
mp-export:  afi ipv6.unicast to AS41051 announce AS64512

Replace AS64512 with your own ASN. Keep the lines for your other upstreams and peers; you are adding to your policy, not replacing it. The request page shows whether the check passed and which line is missing.

Learn more

From registry data to router filters

The whois protocol for Internet routing policy (38C3, 2024) explains IRR, RPSL and filter generation, and where the old whois-based system falls short.
NLNOG IRRexplorer shows IRR data next to what is actually seen in BGP.
bgpq4 generates router filters from IRR data. FreeTransit uses it too.
NLNOG BGP Filter Guide has filtering advice and configuration examples.

Check before activation

Your aut-num exists and is maintained by the right maintainer.
It has direct import and export lines for AS41051.
Every IPv4 prefix you will announce has a route object, and every IPv6 prefix a route6 object.
Each of those objects names your ASN as origin.
Any AS-SETs you maintain for other providers are current. FreeTransit doesn't use them.
Your NOC and abuse contacts work and someone reads them.
Each prefix also has a valid ROA for the same origin.
Your FreeTransit request lists only prefixes your own ASN originates.

Common misunderstandings

Does a route object make an announcement safe?

No. It records your intent and feeds filters, but it proves nothing cryptographically.

Can I skip IRR objects if I have ROAs?

Not yet. Many networks still filter on IRR data, some combined with RPKI. FreeTransit's filter comes from route objects. Publish both.

Can my provider work out my customer cone?

Don't count on it. Give each provider what their onboarding asks for: a maintained AS-SET or an explicit prefix list. For FreeTransit that is your own route objects.

Can the registry objects wait until later?

No. Other operators may build filters before your first announcement, and our activation checks need them. Create and check the objects before the session goes live.

Learn before you apply