What IPv6 block should be whitelisted when a user asks to whitelist their IP?

Currently, on my IPv4-only service, users can whitelist their IP address which allows them to bypass email 2-factor authentication when they log in. When they do this we only whitelist that single IP address since it is assumed that each ISP customer gets their own IPv4 address (at least in the United States).

We want to enable IPv6 support, and after research on how IPv6 subnetting works, we figured out we need to whitelist an entire IPv6 subnet, not a single address.

Searching other IPv6 questions on serverfault, there seems to be conflicting information on what subnet is delegated to each ISP end-user. See this answer:

/56: a block of 256 basic subnets. Even though current policies permit ISPs to hand out blocks as large as /48 to every end user and still consider their address utilisation well justified, some ISPs may (and already do) choose to allocate a /56 to consumer-grade customers as a compromise between allocation

/48: a block of 65536 basic subnets and the recommended size of block that every ISP customer end site should receive.

Just based on that answer, there are already 3 conflicting statements on what IPv6 block each user receives:

• /64: a single subnet, likely the most "economical" block to allocate to end-users
• /56: many ISPs already allocate this to each end-user
• /48: the recommended block each end-user should get

So for a service where IP addresses are used for whitelisting, what IPv6 block is appropriate to whitelist? Should I let the user decide? (The users are fairly tech proficient and would know what a subnet is)

Solution 1:

Prefixes are of varying size because different organizations have more or less networks, and some justified the need to their provider. My residence has a /48 via a Hurricane Electric tunnel simply by clicking a button. (OK, I don't need it but everything just works if each of the wifi networks grab a /64.)

More fundamentally, you seem to be treating an IP address as an authenticator, which it is not. IP addresses are dynamically reassigned, bought, and (mis)routed all the time.

Consider using two factors for the initial login, but not subsequent ones. (Using the existing cookie or Kerberos ticket or whatever.) Ask for one authentication factor when changing sensitive settings, or after some days of not authenticating, or if your system can detect suspicious activity on their account.

For a USA standards body take, see NIST 800-63B. An IP address does not really qualify as an authenticator secret or device. And the maximum time a user should go without reauthentication can be hours or days. If it fits your security requirements, you could leave the user logged in all week. Without an IP address whitelist.

Solution 2:

While many end user ISPs will allocate a larger block than a /64, the majority of end users will only use one /64 from that block for their LAN. Their computer is likely move around within that /64 (thanks to privacy extensions) but is unlikely to move to a different /64 within the allocation from their ISP unless they replace their router (or are one of the few geeks with a router that supports multiple separate subnets, but then those geeks may have more than one IPv4 address as well.........).

So whitelisting a /64 is likely the closest equivalent to whitelisting a single IPv4 IP.

Such whitelists are of course inherently imperfect, but you probably knew that already.