13

Given that Stack Exchange sites ban on IP, I wonder if there's a common opinion or strategy about making rules based on a user's IP in order to dictate behaviors.

With IPv4, you've got a few things you can fairly reliably assume about a given IP:

  1. IPs that share a subnet could very well be the same user
  2. while IPs can be reused for various actual endpoints, it's relatively unlikely that you'll see duplicate connections from an IP that are not the same user, or at the very least the same household/organization (basically, a shared connection)
  3. it's not trivially easy for a user to obtain a new public IP (there is a medium-sized barrier to entry here)

With IPv6, can you assume all of this? I would imagine at the very least the second point would not be true anymore since NAT'ing is supposed to essentially go away with IPv6 because there will be enough IPs for anyone who wants one.

If you have an IP-based set of policies in place, what considerations need to be made for IPv6 if any because of the differences in the two?

Daniel DiPaolo
  • 233
  • 1
  • 7

6 Answers6

6

With IPv6, I don't think there is a perfect solution. But there are a number of things to consider:

  • ISPs will likely give out /64 subnets to individual customers. (There will be enough to go around.)
  • Workplaces will likely have at least one /64 per office.
  • ISPs offering strictly point-to-point links may choose use to use prefixes between /64 and /126. (See why they aren't using /127 in general) This would probably be either a short-sighted ISP, or one who wants to charge more for a full /64. There is really no reason that each endpoint (which could be a full customer network) should not be a /64.
  • Assuming most IPv6 end-user subnets will be on a /64, one could look at bit 6 in the interface identifier (see section 3.2.1 of RFC 4941) to check if it was likely generated based on a globally unique identifier (MAC address). This isn't foolproof, obviously. But if this bit is set, likely indicates that the address was generated from a MAC address. So one could block IPv6 addresses based on the last 64 bits, and users could be blocked no matter which subnet they come from. (Maybe best to use this as a "hint" since MAC addresses, while supposed to be globally unique, in practice aren't always. Plus they are easily spoofed. But anyone savvy enough to go to the trouble would probably find it easier to grab a /64 and get 2^64 unique addresses anyway.)
  • If privacy addresses are in use... not much to do except block that one address for a short time. It'll likely change soon anyway. Factor in the network part of the /64 at this point, but be wary since you might be blocking someone's entire corporate office.

I would say that the best way would be to look first at individual addresses, then factor in the last 64 bits of the address, and patterns of abuse from particular /64 subnets in order to implement a blocking strategy. To summarize:

  • Start by blocking individual /128 IP addresses (like you probably do today with IPv4)
  • If you notice a pattern of abuse from a non-privacy address in the last 64 bits of an address, use that as a strong indicator in your blocking algorithm. Someone could be hopping between ISPs or subnets. (again, be careful with this since MACs are not necessarily unique - someone could be spoofing to exploit your algorithm) Also, this would only work against abusers who don't know how IPv6 works. ;-)
  • If you notice a pattern of abuse from a particular /64, block the entire /64 with a good error message so the offending network's administrator can do whatever work needs to be done on his/her end.

Good luck.

mpontillo
  • 924
  • 6
  • 23
  • 2^64=18,446,744,073,709,552,000 possible addresses. Why on earth do users need that many addresses? – TheLQ Apr 15 '11 at 00:01
  • @TheLQ, they don't, obviously. End-user *networks* do, however, because [RFC 4291](http://tools.ietf.org/html/rfc4291) requires 64-bit interface identifiers. So the last 64 bits, at least on Ethernet networks, will almost be taken up by an [EUI-64](http://tools.ietf.org/html/rfc4291#page-20) address - a 48-bit MAC expanded to 64 bits. Most home networks, rather than a single (static or dynamic) IP address will need a single (static or dynamic) `/64` subnet for this reason, since there is no NAT in IPv6. – mpontillo Apr 15 '11 at 00:09
  • Also, as someone else mentioned, DHCPv6 might help the situation somewhat, but it would possibly put a strain on routers since you'd have to route based on all 128 bits, rather than just the first 64. If you route to individual IP addresses rather than a `/64` per customer, that might explode your routing table to an unreasonable size, and cause problems depending on the hardware being used for routing. – mpontillo Apr 15 '11 at 00:14
  • Thanks, I had no idea that IPs were based upon Mac addresses and forgot that somewhere there's a routing table. Looks like I have some reading to do – TheLQ Apr 15 '11 at 00:24
  • RFC 3627 is now [obsolete](http://tools.ietf.org/html/rfc6547); [RFC 6164](http://tools.ietf.org/html/rfc6164) contains current guidance and recommends using `/127` for point to point links between routers. – Michael Hampton Sep 24 '12 at 18:38
  • 1
    Current best practice [seems to be](http://tools.ietf.org/html/rfc5375#section-2.4.1) that the minimum assignment for an ISP's residential customer be a /56. Of course, most customers probably won't use more than one or two /64 subnets within such a block for quite a while, if ever, but the use is anticipated. – Michael Hampton Nov 20 '12 at 05:39
3

The assumptions you list:

IPs that share a subnet could very well be the same user

Continues to hold -- in fact if ISPs are allocating IPv6 subnets to their customers it becomes even more true.


While IPs can be reused for various actual endpoints, it's relatively unlikely that you'll see duplicate connections from an IP that are not the same user, or at the very least the same household/organization (basically, a shared connection)

Continues to hold (in fact applies to the entire subnet as described above).


It's not trivially easy for a user to obtain a new public IP (there is a medium-sized barrier to entry here)

Doesn't apply to an individual IP so much, but does apply to a subnet handed out by an ISP.


So basically we're looking at subnet bans where we currently have IP bans, assuming ISPs hand out subnets to all their users. If instead users get individual IPv6 addresses (one per user) then we're looking at single IPv6 bans, which may lead to a much longer ban table (and associated performance issues) if there are a lot of badly-behaved users.
In either case an IP ban becomes a more granular tool (i.e. less risk of blocking a bunch of users from an ISP that has a dynamic pool because one person misbehaved), which in my view is a good thing...

voretaq7
  • 79,879
  • 17
  • 130
  • 214
  • 1
    I'll be surprised if mobile networks hand out whole /64s to each phone. They will surely get an IP from a dynamic pool. If LTE takes off in a big way, we could still end up back on "blocking multiple users from an ISP that has a dynamic pool because one person misbehaved". – Richard Gadsden Apr 14 '11 at 12:47
2

Wikipedia/MediaWiki are adopting a policy of blocking a whole /64 when they block the fifth IP within that /64.

Five seems to be the standard rule-of-thumb that others are adopting - the couple of DNSBLs I've seen are adopting the same policy.

I've not seen any plans to aggregate blocks up above a /64, even though getting a /48 or a /56 is pretty easy for even a modest organisation. Of course, spammers currently often have a /24 (IPv4) or so, so I expect that they will start grabbing largish chunks of IPv6 space.

Richard Gadsden
  • 3,686
  • 4
  • 29
  • 58
1

IPs that share a subnet could very well be the same user

Still true, indeed even more true with v6.

while IPs can be reused for various actual endpoints, it's relatively unlikely that you'll see duplicate connections from an IP that are not the same user, or at the very least the same household/organization (basically, a shared connection)

Probablly even more true with v6 than v4.

it's not trivially easy for a user to obtain a new public IP (there is a medium-sized barrier to entry here)

In most cases rather than individual addresses ISPs will be handing out blocks of addresses. It's easy for a customer to move arround within their block. Harder (though far from impossible) to get a new block.

The most difficult bit is that allocation sizes to customers vary wildly. Some ISPs hand out individual addresses, some /64 blocks, some /56 blocks, some /48 blocks.

This will make it hard to come up with a sensible banning/limiting policy that will work for all ISPs. Is that "hot" /48 a single abuser who found an ISP that gave out large blocks or is it a large group of users on a stingy mobile provider that gives out individual addresses.

P.S. Refusing to implement IPv6 isn't really a soloution either as with the IPv4 exhaustion more and more customers will be behind some form of ISP level NAT.

Peter Green
  • 4,211
  • 12
  • 30
0

I think it'll highly depend on what the ISPs will do. Will they continue to provie real dynamic IPs to users? If not, or if every user gets his own ip/subnet exclusively then IPs will start to be pretty much the same as a license plate.

Dexter
  • 597
  • 1
  • 4
  • 5
  • The ISP question boils down to: "Does the ISP want to limit the number of units you can connect to the network?" If no, handing out a /64 to each and sundry will be the route. If yes, I imagine dhcpv6 will dominate. – Bittrance Apr 11 '11 at 20:33
  • 1
    I suspect that /64 will be dominant for home-user-broadband - in fact, a lot of the IPv6 implementations on home CPE ("routers") assume they will be given a /64. OTOH, mobile telecoms providers can prevent tethering by handing out a single IP to each device, and a /64 to users who've paid for tethering. – Richard Gadsden Apr 12 '11 at 12:43
0

When I understood that IPv6 was going to increase the number of IP addresses a lot but not increasing the number of ports per host, I were first puzzled. Given that computers are getting more and more powerful and thus become more capable to servicing a huge number of simultaneous connections, being limited to a max of 65535 ports per IPv6 address seemed to "the next bottleneck".

Then I thought about it once again and realized that it was trivial to assign multiple IPv6 to one physical interface and that way circumvent that limit of the number of ports that can connect to the host. Actually, come to think of it, you can quite easily assign 1024 or 4096 IPv6 addresses to your host and then sort of randomly spread out your services on various ports on all addresses, giving port scanners a fairly harder time (at least in theory).

Now trends like host virtualization (multiple smaller virtual hosts on a relatively powerful physical host) and handheld devices (think IPv6-connected mobiles to everyone on the planet) probably will make might speak against this, most hosts on the future internet probably will use quite few ports and thus only need one single IPv6 address per host.

(But the ability to "hide" in a large pool of IPv6 address, all of which you own and which you can pick from randomly still provides some layer of security, even if admittedly a thin one in most circumstances)

IllvilJa
  • 223
  • 2
  • 7