Hurricane Electric Route Filtering Algorithm

The following is from . This outlines the criteria HE.NET uses for filtering routes from peers and customers.

This is the route filtering algorithm for customers and peers that have explicit filtering:

1. Attempt to find an as-set to use for this network.
1.1 Inspect the aut-num for this ASN to see if we can extract from their IRR policy for what they would announce to Hurricane by finding export or mp-export to AS6939, ANY, or AS-ANY.
1.2 Also see if they set what looks like a valid IRR as-set name in peeringdb.

2. Collect the received routes for all BGP sessions with this ASN. This details both accepted and filtered routes.

3. For each route, perform the following rejection tests:
3.1 Reject default routes and ::/0.
3.2 Reject paths using BGP AS_SET notation (i.e. {1} or {1 2}, etc). See draft-ietf-idr-deprecate-as-set-confed-set.
3.3 Reject prefix lengths less than minimum and greater than maximum. For IPv4 this is 8 and 24. For IPv6 this is 16 and 48.
3.4 Reject bogons (RFC1918, documentation prefix, etc).
3.5 Reject exchange prefixes for all exchanges Hurricane Electric is connected to.
3.6 Reject routes that have RPKI status INVALID_ASN or INVALID_LENGTH based on the origin AS and prefix.

4. For each route, perform the following acceptance tests:
4.1 If the origin is the neighbor AS, accept routes that have RPKI status VALID based on the origin AS and prefix.
4.2 If the prefix is an announced downstream route that is a subnet of an accepted originated prefix that was accepted due to either RPKI or an RIR handle match, accept the prefix.
4.3 If RIR handles match for the prefix and the peer AS, accept the prefix.
4.4 If this prefix exactly matches a prefix allowed by the IRR policy of this peer, accept the prefix.
4.5 If the first AS in the path matches the peer and path is two hops long and the origin AS is in the expanded as-set for the peer AS and either the RPKI status is VALID or there is an RIR handle match for the origin AS and the prefix, accept the prefix.

5. Reject all prefixes not explicitly accepted

Internet Routing Registry Resources by j2sw

What is a routing registry?
From Wikipedia
The Internet routing registry works by providing an interlinked hierarchy of objects designed to facilitate the organization of IP routing between organizations, and also to provide data in an appropriate format for automatic programming of routers. Network engineers from participating organizations are authorized to modify the Routing Policy Specification Language (RPSL) objects, in the registry, for their own networks. Then, any network engineer, or member of the public, is able to query the route registry for particular information of interest.

RFC2622 Routing Policy Specification Language (RPSL)

RFC2650 Using RPSL in Practice

RFC7682 Considerations for Internet Routing Registries (IRRs) and routing Policy Configuration

General IRR Information
Includes links to various registries, FAQs, and other info
NTT route registry FAQ
Seattle Internet Exchange IRR Tutorial
NANOG Routing registry tutorial

General How-Tos
A Quickstart Guide to Documenting Your Prefixes with IRR. This mainly uses the older ARIN e-mail templates.

Arin Specific
Arin’s userguide for working with their IRR
Notes on working with ARINs web-based

Other Regional Registries

African Network Coordination Centre (AFRNIC)

Asian-Pacific Network Coordination Centre (APNIC)

American Registry for Internet Numbers (ARIN)

Latin American and Caribbean Internet Addresses Registry (LACNIC)

Reseaux IP Eauropeens Network Coordination Centre (RIPE NCC)

A collection of tools which allow ISPs to easily track, manage, and utilize IPv4 and IPv6 BGP routing information stored in Internet Routing Registry (IRR) databases. Some of these tools include automated IRR data retrieval, update tracking via CVS, e-mail notifications, e-mail based notification for ISPs who still do human processing of routing information, and hooks for automatically deploying prefix-lists on routers.
The RADB whois server provides information collected from all the registries that form part of the Internet Routing Registry.
Internet Routing Registry daemon version 4 is an IRR database server, processing IRR objects in the RPSL format.

RPKI and misconceptions

After my blog post about Hurricane Electric and RPKi support, I was seeing some comments by folks that warrant some clarification. I put together a short midnight podcast on this.  To summarize
1. route original validation is not the same as having ROA’S with your RIR
2. If you have an ASN you should have a peering DB entry
3.ROAs have nothing to do with your router supporting RPKI

Hurricane Electric now requires IRR and filters invalid RPKI

If you are a Hurricane Electric customer you may be receiving e-mails like the following:


Routing Security Report for ASXXX

Hurricane Electric cares about your routing security.  We filter all BGP sessions using prefix filters based on IRR and RPKI.

This report is being sent to help you identify prefixes which may need either their IRR or RPKI information created or updated 
and to also help you identify possibly hijacked routes you may be accepting and reannouncing.  

Routes with RPKI status INVALID_ASN strongly indicate a serious problem.


Routes accepted: 3
Routes rejected: 3
Routes with RPKI status VALID: 0
Routes with RPKI status INVALID: 0


Routes accepted: 1
Routes rejected: 0
Routes with RPKI status VALID: 0
Routes with RPKI status INVALID: 0

We currently do not have a valid as-set name for your network.  Please add an export line to your aut-num ASXXXX 
that references your as-set name.  For example,

export: to AS-ANY announce your-as-set-name

If you do not currently have an as-set, we recommend you create one named ASXXXX:AS-ALL

Your as-set should contain just your ASN and your customers' ASNs and/or as-sets (not your peers or upstream providers).

What does this mean for you as a service provider? If you use Hurricane Electric as transit or peer with them on an exchange you will need to have ROAs for your blocksand have routing registry objects. I did a tutorial based upon Arin which can be found at:

In short you need to do the following:

  • Create a mntner object (equivalent of a user account) to give you the ability to create IRR objects in your selected IRR database
  • Create an aut-num to represent your autonomous system and describe its contact information (admin and technical) and your routing policy
  • Create an as-set to describe which autonous system numbers your peers should expect to see from you (namely your own and your transit customers)
  • Create a route/route6 object for every prefix originated from your network
  • Update your peeringdb profile to include your IRR peering policy
  • Generate RPKI

Some folks are confusing having valid ROAs with your router supporting RPKI with route origin validation in real-time. These two are separate things. You create ROA records with your RIR, such as ARIN, which has nothing to do with route validation on your router.

Also, HE is filtering any RPKI INVALID routes. Does this mean they are requiring RPKI? You be the judge.

The problem with routing registries

Anyone who has followed me or I have done IP work for knows I am a fan of Internet Routing Registries (IRR).  However, there is a glaring issue with these registries.  I will use the example I ran into today.

A downstream client of a WISP client bought off the open market about a year ago.  They finally have things in place where they are looking to announce this IP space to the world.  I helped them set up BGP to my client ISP and sent out the normal LOAs to the upstream providers.  I received this back from Hurricane Electric.

The IRR entry for this prefix does not list 14333.
Please update IRR and let me know. I can add this to your prefix filter.

And a Subsequent followup message

I can add this prefix to your filter, based on the LOA. However the reason we require IRR entries for prefixes is because our peers only accept our re-announcements if there are correct IRR entries authorizing the announcement. 

Can you confirm what the source ASN will be for this announcement?
If a customer of yours is going to re-announce this to you, and that ASN is listed on:
Then this will work. However if you plan to announce this sourced from your ASN 14333, this will not be picked up past our network.

This highlights one of the glaring issues with registries.  There are no checks and balances when it comes to stale data in registries. The same is true with access lists in provider routers.

What I am guessing happened is when the /20 block was carved up and sold it’s information was never removed from the routing registry.  Since this is RADb and it does not talk directly with ARIN we have some inconsistencies going on.

The following RFC illustrates many of the issues folks run into.
From the summary of the document

As discussed above, many of the problems that have traditionally stifled IRR deployment have, themselves, become historical. However, there are still real operational considerations that limit IRR usage from realizing its full effectiveness.

To further complicate this Hurricane Electric is referencing data in RADb, which is a paid registry.

So what are am I going to have to do? In order to make this right, I will have to reach out to RADB and have them edit the registry to start with. Since this customer, nor the ISP, are members of RADb it will take time.