FAIRVISOR Docs
⌘K
GitHub fairvisor.com

ip:type

ip:type is a descriptor for network-type-aware policy decisions.

It is useful when you want different limits for traffic origins such as hosting providers, business networks, or ISPs.

Descriptor key

Use in rules as:

"limit_keys": ["ip:type"]

Or in match conditions:

"match": {
  "ip:type": "hosting"
}

Values

Values are sourced from ipverse/as-metadata categories plus Fairvisor enrichment:

Value Network type
business Business and enterprise networks
education_research Educational institutions and research organizations
government_admin Government and administrative networks
hosting Hosting providers and data centers
isp Internet Service Providers
unrouted ASN has no routed prefixes in enrichment datasets
unknown Unmapped ASNs (default fallback)

Always include a rule or fallback that handles unknown to avoid unintended fail-open behavior.

Paid plans ship with an enhanced mapping dataset that reduces unknown coverage and improves classification accuracy for business, hosting, and ISP ranges. See Pricing for details.

Example: stricter limiter for hosting networks

{
  "name": "hosting-rps",
  "limit_keys": ["ip:type", "ip:address"],
  "algorithm": "token_bucket",
  "algorithm_config": {
    "tokens_per_second": 20,
    "burst": 40
  },
  "match": {
    "ip:type": "hosting"
  }
}

nginx integration pattern

Fairvisor reads ip:type from the X-ASN header via asn_type.map at runtime.

Typical nginx pattern:

http {
  # ASN must already be available as $asn (for example via geoip2 ASN module)

  map $asn $asn_type {
    include /etc/fairvisor/asn_type.map;
    default unknown;
  }

  server {
    location = /_fairvisor_decision {
      proxy_pass http://fairvisor_edge/v1/decision;
      proxy_set_header X-ASN        $asn;
      proxy_set_header X-ASN-Type   $asn_type;
      proxy_set_header X-Original-Method $request_method;
      proxy_set_header X-Original-URI    $request_uri;
    }
  }
}

asn_type.map is generated from ipverse/as-metadata and Fairvisor enrichment during the build/update step.

Operational notes

  • ip:type quality depends on asn_type.map coverage; unmapped ASNs fall back to unknown.
  • Keep a safe fallback for unknown to avoid silent fail-open behavior in policy intent.
  • Do not use ip:type as a single security signal; combine with identity and route-based controls.

MD