--- Comment #25 from Philippe Verdy <verd...@wanadoo.fr> 2011-03-05 00:12:48
Extensive tests must effectively handled now in high priority. In the next few
months, we'll start experiencing with the problem of users that won't be able
to use Wikimedia sites in some countries, just because they won't be able to
have a stable enough IPv4 address (the Ipv4 support will be through proxies,
and there will be problems in validating the proxies to make sure that they
effectively handle the proxying signaling on their HTTP requests, ot identify
sessions), and that won't also be able to use HTTPS for strong identification
to paliate this problem.
Promoting the use of IPv6 should also be an easy alternative if their temporary
(and shared) IPv4 address is compromized (by some unrelated abusers), because
it won't be acceptable to block IPv4 addresses without making sure that the
IPv6 support is there and working for those users.
If we don't act now, we will be left without easy solution to fight against
abuses. Those users may eventually still use HTTPS, but it will have a severe
performance impact on servers, if HTTPS usage suddenly increases.
So there's an immedaite need to test for complete support at least for the
major Mediawiki servers, notably those from Wikimedia due to their huge
worldwide traffic, but also all other services that should be candidate for
testing their deployment if they use another webserver system than Apache. The
tests should then include IIS, and progresivly all webservers that support PHP
builds (including the various incarnations of FastCGI), on Linux, BSD, Windows
(IIS), or application servers (Oracle, IBM Websphere...).
Now the minutes start being counted. The "Bug Bang" is about to appear, do we
have to wait for a major connectivity failure or the start of major abuse
attacks through 6to4 or Teredo servers or many proxies that we'll consider as
unsecured openrelays throughout the world ? Are we ready to support a suddent
increase of use of HTTPS? And the loss of support of HTTP/1.1 sessions for a
suddent increase of isolated HTTP sessions (one for each request)?
Note how the various ISPs worldwide are very late in deploying IPv6, the only
thing they have tested for now are Teredo or 6to4 relays, but only for a small
part of the traffic, as they think that almost everything is cachable and
sharable to support the load. This may be true for media delivery sites
(including images, sound and videos), but not for interactive sites like
Wikimedia and all wikis and blogs in general.
The largest interactive sites are already OK for IPv6 (including Google, Yahoo,
Microsoft, Facebook). If we don"t resolve this connectivity problem very soon,
the Wikimedia popularity could extremely rapidly slow down (remember that it
not only depends on individual users, but also on their capability of
socializing on these sites; if a friend or important team member can no longer
participate easily, due to the technical measures that its ISP may take to
appliate the lack of Ipv4 addresses to support all their users, or due to the
increased cost for their IPv4 address pool, and a drastic reduction of this
pool, as this seems the case, given that they seem to favor solutions like LSN
= Large-Scale-NAT) it could be catastrophic for Wikimedia.
Note that some interactive networks have already chosen to stop using MediaWiki
for their wikis (note the suddent increase of Mediapress, which also offers
more interesting 2.0 social features, and simpler administration from users,
and a much less important role for superusersn and better syndication
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list