OpenRTB carries device.ipv6 beside device.ip. IPv4-only datacenter blocks miss the parallel path.

What the metric actually measures

Datacenter blocklists are not impression IVT scores. They are weekly CSV files of CIDR ranges associated with cloud and hosting providers, intended to be matched before an auction prices inventory. The Media Rating Council expects filtration of invalid datacenter traffic to include ranges from the three largest hosting providers: Amazon AWS, Google, and Microsoft. Vendor feeds extend that with internally curated ranges for smaller clouds.

That is a different population from device reputation lists, which attach fraud types and probabilities to individual IPs and update on a faster cadence (IPv6 device lists twice per day in one vendor schema). Datacenter lists answer a narrow question: does this address belong to infrastructure that should not originate a consumer ad impression? Pre-bid means the check runs on the bid request, not on the rendered pixel.

The transitional market state matters. IPv4 and IPv6 coexist on residential and wireless interfaces for years. One vendor FAQ walks through a household example: if only 10 percent of impressions behind an IPv4 are invalid, blocking the entire address rejects the other 90 percent. When IPv6 is available for that bad slice, a separate v6 check can block the invalid fraction without touching the rest. That only works if your stack actually reads device.ipv6 and maintains a v6 datacenter feed, not if you treat IPv4 as the only network identity in OpenRTB.

The mechanism on the bidstream

OpenRTB places both addresses on the same device object. They are optional and independent. An SSP assembling requests from dual-stack CTV hardware may populate one, both, or swap which field reflects the path the ad server saw. Fraud originating from cloud VMs, proxy farms, or misconfigured SSAI often arrives with a datacenter footprint on whichever field your integration ignores.

// Same impression, two network claims
"device": {
  "ip": "73.42.18.104",                    // household NAT, looks residential
  "ipv6": "2607:f8b0:4001:c06::65",          // may map to hosting range
  "ua": "...",
  "ifa": "..."
}

// IPv4-only datacenter match: pass (residential range)
// IPv6 datacenter match: no-bid (cloud CIDR hit)
// Check only device.ip: buyer never sees the failure mode

IPv6 adoption is concentrated where CTV lives. Residential ISPs report IPv6 interface adoption above 90 percent in many cases, even while most observed traffic volume is still IPv4. CTV devices behind a single router share one public v4 address; v6 gives per-device granularity that changes both targeting and fraud detection economics. None of that helps if the bidder normalizes everything to v4 or drops requests missing device.ip while silently accepting datacenter v6.

Integration is not a flag flip. One vendor notes that clients may operate separate IPv4 and IPv6 servers for blocking because the address formats and observation points differ. A given IPv4 can map to multiple IPv6 addresses; threat intel may flag specific v6 prefixes while leaving the v4 unlisted to avoid collateral damage. Pre-bid fabric delivery (API, object storage, RTB fabric hooks) must load both weekly datacenter files. Datacenter feeds update on Fridays; checking hourly on Friday is the documented integration pattern when new CIDR files land.

Proxies add a second axis. When an X-Forwarded-For chain is present, datacenter guidance says to treat the leftmost client IP as authoritative for matching, but also to scan other hops in the chain against blocklists even when the client IP is clean. Proxy hops often classify as datacenter or masked IP in post-bid IVT taxonomies. That is adjacent to, not a substitute for, matching device.ipv6 on the OpenRTB object itself.

What to do

• Match datacenter CIDRs against both device.ip and device.ipv6 at pre-bid. Maintain separate v4 and v6 lists; do not assume blocking one protocol covers the other.
• Log which field triggered a block. Dashboards that only report "IP block" hide whether v6 coverage is missing. A falling datacenter IVT rate on v4 with flat spend can mean fraud moved to v6.
• Do not treat absent device.ipv6 as proof of v4-only supply. Missing fields are common; so is dual-stack hardware that your adapter never forwarded. Sample raw requests in the bid request tester before changing block policy.
• Separate datacenter blocks from device reputation thresholds. Reputation feeds use probability scores; datacenter lists are binary CIDR membership. Conflating them in one rule engine makes tuning impossible.
• Validate shape before policy. An IPv6 string with wrong formatting never reaches your CIDR matcher. Gate OpenRTB device objects in CI per the validation guide so policy runs on payloads that parse consistently.

The honest limit

CIDR blocklists are vendor-maintained opinions about hosting ranges, refreshed weekly. They will not catch residential botnets, delisted CTV apps, or spoofed bundle IDs. They also cannot prove an impression rendered on a living-room screen. They close one specific hole: cloud-originated traffic riding the alternate IP field your stack was not checking. During a multi-year dual-stack transition, that hole is large enough to matter in the bidstream even when headline IVT rates look stable on defended campaigns.

Sources

Field names are from OpenRTB as published by IAB Tech Lab. The analysis is our own. RTBlint is independent and not affiliated with IAB, IAB Tech Lab, or Pixalate.

• Pixalate: Data Center Block List knowledge base (IPv4 and IPv6 feeds, MRC scope, weekly cadence)
• Pixalate: Blocking FAQ (dual-stack rationale, 10 percent household example, IPv6 update cadence)
• RTBlint: OpenRTB bid request reference (device.ip, device.ipv6)