Blocking IPv6 Traffic on Shopify

Most merchants learned IP blocking in the IPv4 era, where a single address like 203.0.113.45 maps roughly to one connection. That mental model breaks the moment you look at IPv6. A single mobile carrier or hosting provider can hand out billions of IPv6 addresses to what is effectively one device or one bad actor. If you block IPv6 the way you blocked IPv4, you will either miss the attacker entirely or accidentally wall off half your mobile traffic.

This guide explains how IPv6 addressing actually works from a fraud-prevention angle, and how to build blocklists that hit the abuser without collateral damage.

Why IPv6 breaks single-address blocking

An IPv6 address is 128 bits, written as eight groups of four hex digits, for example:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

Compare that to IPv4's 32 bits. The address space is astronomically larger, and providers exploit it. Here is the practical problem:

• A shopper's phone can generate a new IPv6 address for every session using SLAAC privacy extensions.
• A fraudster on a hosting provider can rotate through thousands of addresses in minutes without buying anything new.
• Blocking 2001:db8:85a3::7334 stops exactly one address that the attacker will never reuse.

Signals. If you see the same fraudulent behavior arriving from addresses that all share the same leading digits but differ in the last chunks, you are not looking at many attackers. You are looking at one attacker inside one allocation.

Understanding the /64 prefix

The key unit in IPv6 is the /64 prefix — the first 64 bits of the address. By convention, ISPs and hosting providers assign each customer a block, and the smallest routable unit is almost always a /64 (or larger, like a /56 or /48 for whole networks).

Think of it this way:

• The first 64 bits identify the network or subscriber.
• The last 64 bits identify the specific interface, and these change constantly.

So 2001:db8:85a3:1111::/64 covers every address from 2001:db8:85a3:1111:0000:0000:0000:0000 through 2001:db8:85a3:1111:ffff:ffff:ffff:ffff. That is over 18 quintillion addresses — all belonging to the same assignment.

Best control. When you want to block an IPv6 abuser, block the /64, not the individual address. This catches every rotation the attacker makes within their allocation while remaining precise enough to avoid the wider network.

When to widen the mask

Sometimes a /64 is not enough. Larger fraud operations run out of a full customer allocation — a /56 (256 subnets) or a /48 (65,536 subnets). If blocking a /64 only slows the attack for a few minutes before addresses reappear from an adjacent prefix, escalate:

The danger climbs as you widen: a /48 on a residential ISP could sweep up an entire neighborhood of legitimate shoppers. Reserve wide masks for datacenter and hosting ranges where no real customer traffic should originate anyway.

Protecting your mobile shoppers

This is where IPv6 blocking gets risky. Mobile carriers were early and aggressive IPv6 adopters, and a huge share of your mobile checkout traffic arrives over IPv6. Careless range blocking can silently kill conversions.

A few rules keep you safe:

• Never block a mobile carrier's parent allocation. Carriers use large shared prefixes. Blocking wide there means blocking real buyers.
• Distinguish residential/mobile from hosting. Fraud from a /64 on a known VPS provider is a clean block. The same pattern from a mobile carrier deserves scrutiny before any range action.
• Prefer behavior-based blocks over static ranges for mobile. Because carrier addresses churn, a shopper who was fine yesterday may inherit a previously flagged address. Time-boxed or behavior-triggered blocks avoid punishing innocents.

Signals. Datacenter IPv6 ranges rarely carry genuine retail purchases. If checkout attempts originate from ASNs belonging to cloud or hosting providers, that alone is a strong fraud indicator regardless of the specific /64.

Where Shopify leaves a gap

Shopify's native tools do not expose granular IPv6 range controls, and manually maintaining CIDR blocklists across /64, /56, and /48 boundaries is not realistic for most stores. You also cannot easily tell, from Shopify's order data alone, whether an address belongs to a mobile carrier or a datacenter.

This is the practical case for a dedicated layer. Shieldy Fraud Filter evaluates both IPv4 and IPv6 traffic at the checkout level, classifies the source (residential, mobile, hosting, VPN, proxy, Tor), and lets you block by prefix rather than fighting single addresses that never return. Because the classification runs before the order completes, you stop card-testing and rotation attacks without hand-maintaining CIDR math.

A practical blocking workflow

Put it together into a repeatable process:

1. Identify the pattern. Group suspicious orders by their leading 64 bits, not the full address.
2. Classify the source. Is it mobile, residential, or datacenter? This decides how wide you can safely go.
3. Start narrow. Block the /64 first and watch for the attack to reappear.
4. Escalate only if needed. Move to /56 or /48 for confirmed hosting ranges, never for mobile.
5. Time-box residential blocks. Addresses churn; a permanent residential block risks catching future legitimate buyers.
6. Monitor conversion. A sudden drop in mobile checkout completion is your early warning that a block went too wide.

The takeaway

IPv6 rewards precision and punishes the old IPv4 habits. Block the /64 for standard abuse, widen only for datacenter ranges, and treat mobile carrier space as almost untouchable. Match the mask to the source, and you filter the attacker while keeping every real mobile shopper checking out cleanly.

If you would rather not hand-calculate prefixes for every incident, let a checkout-level filter handle the classification and range logic for you — see how Shieldy Fraud Filter approaches it.