as-ip-blocks gives you one directory of announced prefixes per autonomous system, refreshed daily

The data model, one directory per AS

as-ip-blocks, formerly asn-ip, is a set of daily-updated datasets of autonomous systems with active BGP prefix announcements. Only AS that have announced at least one prefix within the last 90 days are included. There are no APIs and no databases, just simple file downloads.

Each AS gets its own directory with aggregated IPv4 and IPv6 prefixes in both JSON and plaintext formats. The repository root contains the as/ directory plus a .gitignore, the LICENSE and the README.

The aggregation is worth explaining because it changes what you get. Prefixes are aggregated, meaning adjacent and overlapping CIDR blocks are merged into larger blocks where possible. That is not a cosmetic tidy-up. A provider announcing 500 small prefixes becomes a handful of large ones, which is the difference between a usable firewall rule set and thousands of rules.

The framing in the README is that this is perfect for firewall rules, network analysis, or tracking what IP ranges belong to specific organizations. And the git history is called out as a feature in its own right: it lets you see how an AS's announcements change over time, which is useful for tracking a provider adding or dropping capacity.

The licence is CC0 1.0 Universal, which puts the data in the public domain, and the primary language is recorded as unknown because the repository is data rather than code.

The JSON format and the fields it carries

The JSON format is the richer of the two, and the README shows it with a worked example.

{
  "asn": 1234,
  "metadata": {
    "handle": "FORTUM",
    "description": "Fortum",
    "countryCode": "FI",
    "country": "Finland",
    "origin": "authoritative",
    "category": "business",
    "networkRole": "stub"
  },
  "prefixes": {
    "ipv4": [
      "132.171.0.0/16",
      "137.96.0.0/16",
      "193.110.32.0/21"
    ],
    "ipv6": [
      "2405:1800::/32"
    ]
  }
}

The metadata block carries the AS handle, the description, the country code and name, the BGP origin, and two fields added on 2026-02-08, `category` and `networkRole`.

The country fields are what make the data useful beyond routing, since they turn an AS number into an attributable organisation. The origin field distinguishes authoritative announcements from those seen from other peers, which is a meaningful distinction when you are reasoning about how much trust a prefix list deserves.

The README points at the separate as-metadata repository for metadata field descriptions and possible values, so the enumeration of what category and networkRole can hold is documented there rather than here.

One structural note. The prefixes key holds two lists, ipv4 and ipv6, in the same file, so a single download gives you both families and you filter client-side.

The plaintext format, and why you might want it

The plaintext format is a comment header followed by one prefix per line, and it is the form you will feed to a firewall or a text pipeline.

# AS1234 (FORTUM)
# Fortum
#
132.171.0.0/16
137.96.0.0/16
193.110.32.0/21

IPv6 uses the same shape.

# AS1234 (FORTUM)
# Fortum
#
2405:1800::/32

The format is trivially parseable, with the identifier as a comment so the file is still valid in a sense to tools that expect nothing but addresses, and the third line of bare hashes keeps the separator consistent between the two address families.

There are two separate plaintext files per AS, ipv4-aggregated.txt and ipv6-aggregated.txt, rather than one combined file. That is a deliberate choice for firewall use, where you want to feed each family into the matching ruleset without splitting it yourself, and it does mean two requests where the JSON would have been one.

The same two files also exist in the aggregated JSON, as the ipv4 and ipv6 lists inside prefixes, so the choice between the formats is about what you do with the result rather than about what data you get.

Fetching the data, one AS or all of them

Per-AS downloads go through raw.githubusercontent, and the file names are predictable.

AS1234 in JSON format:

curl https://raw.githubusercontent.com/ipverse/as-ip-blocks/master/as/1234/aggregated.json

AS1234 IPv4 addresses:

curl https://raw.githubusercontent.com/ipverse/as-ip-blocks/master/as/1234/ipv4-aggregated.txt

AS1234 IPv6 addresses:

curl https://raw.githubusercontent.com/ipverse/as-ip-blocks/master/as/1234/ipv6-aggregated.txt

And for everything at once there is a bulk archive from the latest release.

curl -LO https://github.com/ipverse/as-ip-blocks/releases/latest/download/as-ip-blocks.tar.gz
tar -xzf as-ip-blocks.tar.gz

That bulk archive was added on 2026-01-17, and it is the route to take if you are building the whole dataset. Fetching per AS over raw.githubusercontent works fine for one or two lookups, but it is one request per AS and it does not scale to a full inventory, and the tarball is a single download of the same data.

There is also an online viewer. The README points to Lens by ipverse at lens.ipverse.net, where you can look up any AS or IP prefix to explore announced prefixes and metadata, which is the fastest way to sanity-check what a given AS actually announces before you write a rule against it.

The related project as-metadata is the companion for the complete metadata dataset, including the lastAnnounced timestamps and additional fields not included in the per-AS files here.

Firewall use, and the tools that consume it

The README has a specific section on firewalling, and it links two projects rather than describing its own integration.

nftables-blacklist is an nftables based Bash script, and ipverse-tools-crowdsec bans prefixes using Crowdsec's cscli command. The framing is that if you plan to use the routing data for firewalling purposes, you should have a look at these.

That is an honest pointer rather than a copy of the docs, and it reflects the scale of the problem. Turning this data into firewall rules means generating an nftables set or driving Crowdsec, and neither is a one-line job when the input is thousands of prefixes per provider.

The use cases listed cover the range. Blocking an entire AS at the firewall, described as goodbye spam-friendly hosting providers. Checking what routes an AS is announcing, using the git history to track changes over time. Network research and statistical analysis. Threat hunting and security research. Figuring out which IPs belong to a specific organisation. And, in the README's own summary, pretty much anything where you need to map ASNs to their announced prefixes.

One caveat on the blocking case specifically. This is a list of what a provider announces, not a list of what is malicious. Using it as an allowlist or a denylist is a policy decision about an organisation's whole address space, and a provider can announce addresses for other organisations.

The update notes, which explain the moving target

The README carries a chronological list of changes, and reading it tells you the format has changed more than once.

On 2026-01-03 the repository was renamed to as-ip-blocks and the JSON format changed, with subnets becoming prefixes and the metadata nested. On 2026-01-05 the lastAnnounced field was removed to reduce git delta size, with that field still available in as-metadata. On 2026-01-08, AS directories are now removed if no prefixes have been announced in the last 90 days, with historical metadata for removed AS possibly still available in as-metadata. On 2026-01-17 a bulk download archive was added in the releases. On 2026-02-08 the category and networkRole fields were added to the JSON metadata.

Earlier entries go back further, with 2025-08-03 recording the removal of opinionated handle cleanup and 2023-09-03 the removal of PEM certificates from the description field.

Two of those matter for anyone automating against this data. The directory removal policy means an AS that stops announcing simply vanishes from the repository, so a consumer that enumerates the as/ directory needs to handle an AS that used to exist and now does not. And the field removal and renaming mean a consumer written against an older copy of the format will break without noticing, because the file still parses as JSON and the field is simply absent.

The two repositories together are the durable arrangement: as-ip-blocks for the prefix data and as-metadata for the descriptive fields, including the ones that get dropped to keep the git delta small.

Where as-ip-blocks is the wrong choice

Four cases argue against it.

The first is a real-time requirement. This is a daily-updated dataset served as files, with a 90 day inclusion window and directory removal for quiet AS. If your decision needs to reflect an announcement from five minutes ago, this is the wrong source, and a live BGP feed or a routing looking glass is the right one.

The second is attribution. The data says which prefixes an AS announces. It does not say who operates the addresses inside them. Cloud providers and hosting firms announce space for many unrelated organisations, and a blocklist built on ASN membership will block more than you think. If your need is attribution to a named end customer, you need a different dataset.

The third is a workflow with a fixed schema. The format has changed twice in the last year, once with the rename and the subnets to prefixes change and once with fields being removed to shrink the git delta. Anything that consumes this needs to be version-aware, and the README gives you no format version marker to key off.

The alternative in the same direction is a live routing data source such as a RouteViews or RIPE RIS archive, or a BGP collector's export, which give you the full picture of announcements rather than the aggregate per AS. The difference in approach is that those sources give you history and per-peer views, at the cost of processing a lot of data, whereas as-ip-blocks gives you a pre-aggregated, pre-joined answer for the common question of which prefixes does this AS own, as a file you can curl. For a firewall rule set or a research dataset that you regenerate periodically, the pre-aggregation is exactly what you want and the format churn is a cost you accept in exchange.

Editorial conclusion

as-ip-blocks fits a network engineer who needs to turn an AS number into the address space it currently announces, whether for firewall rules or research, since the aggregation and the two formats remove the raw prefix handling from your side. It does not fit a workflow that depends on a stable schema over time, because the format changed when the repository was renamed and directories are removed when an AS goes quiet. Pin to the format you need, fetch the tar.gz archive rather than parsing git history, and treat any blocklist built from it as a dated capture rather than a live feed.

Frequently asked questions

Official sources

1. ipverse/as-ip-blocks on GitHub
2. Issues
3. License: CC0-1.0
4. README
5. Releases