In article AANLkTim3ht9HXaU3sgwMfu9mPh9Gb2Rx2MiSg3VMCiie@mail.gmail.com, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
I'm glad this thread soon got to the point where we realise the problem is on the application layer level.
If that was the only problem, this would be much simpler.
So what are exactly the implications for blocking and related issues when we will start to see ISP level NATing?
Users will either need to move to an ISP that supports IPv6, or accept that they will be frequently blocked on Wikipedia for no reason.
Am I right to assume that we will start seeing requests from say a global ISP NAT which may cover many clients, XFF 10.x.x.x?
NATs cannot send XFF headers. If ISPs deploy transparent proxies for HTTP (in conjunction with CGNAT for other traffic), then they might start sending XFF.
At the moment I don't think it's clear how ISPs are going to handle this.
If so, do we need to be able to send both the ISP NAT IP, and the XFF IP to the servers, and amend the software so that we are able to block on the combination (so we can block, for example IP 9.10.11.12 XFF 10.45.68.15?)
Most NATs use a pool of addresses rather than a single address; this means that the ISP address could change on every request, even from the same user. So, I don't know if the RFC1918 address will have any value at all.
- river.