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:

ValueNetwork type
businessBusiness and enterprise networks
education_researchEducational institutions and research organizations
government_adminGovernment and administrative networks
hostingHosting providers and data centers
ispInternet Service Providers
unroutedASN has no routed prefixes in enrichment datasets
unknownUnmapped 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.