I just checked and determined that there appear to be no AAAA records yet for the WMF servers.
I have to admit to having been negligent in examining the IPv6 readiness of the Mediawiki software. Is it generally working and ready to go on IPv6?
Does the Foundation have a IPv6 support plan ready to go?
The importance of this is going to be high in the Asia-Pacific region within a few months: http://www.potaroo.net/tools/ipv4/rir.jpg
(APNIC runs out of IPv4 space to give to providers somewhere around August, statistically; RIPE in Feb or March 2012, ARIN in July 2012).
In each region, ISPs then will start running out of IPv4 to hand out within a month to three months of the registry exhaustion.
We have a few months, but by the end of 2012, any major site needs to be serving IPv6.
Out of curiosity, is anyone from the Foundation on the NANOG mailing lists?
----- Original Message -----
From: "George Herbert" george.herbert@gmail.com
I just checked and determined that there appear to be no AAAA records yet for the WMF servers.
I have to admit to having been negligent in examining the IPv6 readiness of the Mediawiki software. Is it generally working and ready to go on IPv6?
Is Apache? That's the base question, is it not? I think the answer is yes.
The importance of this is going to be high in the Asia-Pacific region within a few months: http://www.potaroo.net/tools/ipv4/rir.jpg
(APNIC runs out of IPv4 space to give to providers somewhere around August, statistically; RIPE in Feb or March 2012, ARIN in July 2012).
ARIN issued the last 5 available /8s to RIRs *today*; we've been talking about it all day on NANOG.
In each region, ISPs then will start running out of IPv4 to hand out within a month to three months of the registry exhaustion.
We have a few months, but by the end of 2012, any major site needs to be serving IPv6.
Out of curiosity, is anyone from the Foundation on the NANOG mailing lists?
Oh yeah; that's what triggered this. :-)
Cheers, -- jra
In article 19663836.4613.1296766691647.JavaMail.root@benjamin.baylink.com, Jay Ashworth jra@baylink.com wrote:
----- Original Message -----
From: "George Herbert" george.herbert@gmail.com I have to admit to having been negligent in examining the IPv6 readiness of the Mediawiki software. Is it generally working and ready to go on IPv6?
Is Apache? That's the base question, is it not?
It doesn't matter if Apache supports IPv6, since the Internet-facing HTTP servers for wikis are reverse proxies, either Squid or Varnish. I believe the version of Squid that WMF is using doesn't support IPv6.
As long as the proxy supports IPv6, it can continue to talk to Apache via IPv4; since WMF's internal network uses RFC1918 addresses, it won't be affected by IPv4 exhaustion.
Apache does support IPv6, though; some other content which is served using Apache, like lists.wm.o, is available over IPv6.
MediaWiki itself supports IPv6 fine, including for blocking. This was implemented a while ago. Training admins to handle IPv6 IPs could be interesting.
(APNIC runs out of IPv4 space to give to providers somewhere around August, statistically; RIPE in Feb or March 2012, ARIN in July 2012).
ARIN issued the last 5 available /8s to RIRs *today*; we've been talking about it all day on NANOG.
Not exactly. IANA issued the last 5 /8s to RIRs, of which ARIN is one, today. But George is talking about RIR exhaustion, which is still some months away.
Out of curiosity, is anyone from the Foundation on the NANOG mailing lists?
Oh yeah; that's what triggered this. :-)
Does any useful discussion still take place on that list?
- river.
----- Original Message -----
From: "River Tarnell" r.tarnell@IEEE.ORG
It doesn't matter if Apache supports IPv6, since the Internet-facing HTTP servers for wikis are reverse proxies, either Squid or Varnish. I believe the version of Squid that WMF is using doesn't support IPv6.
Oh, of course.
As long as the proxy supports IPv6, it can continue to talk to Apache via IPv4; since WMF's internal network uses RFC1918 addresses, it won't be affected by IPv4 exhaustion.
It might; how would a 6to4NAT affect blocking?
Apache does support IPv6, though; some other content which is served using Apache, like lists.wm.o, is available over IPv6.
MediaWiki itself supports IPv6 fine, including for blocking. This was implemented a while ago. Training admins to handle IPv6 IPs could be interesting.
I mused on NANOG yesterday as to what was going to happen when network techs started realizing they couldn't carry around a bunch of IPs in their heads anymore...
(APNIC runs out of IPv4 space to give to providers somewhere around August, statistically; RIPE in Feb or March 2012, ARIN in July 2012).
ARIN issued the last 5 available /8s to RIRs *today*; we've been talking about it all day on NANOG.
Not exactly. IANA issued the last 5 /8s to RIRs, of which ARIN is one, today. But George is talking about RIR exhaustion, which is still some months away.
His phrasing seemed a bit.. insufficiently clear, to me. That was me, attempting to clarify.
Out of curiosity, is anyone from the Foundation on the NANOG mailing lists?
Oh yeah; that's what triggered this. :-)
Does any useful discussion still take place on that list?
Sure. The S/N is still lower than the Hats would prefer, but that's the nature of an expanding universe.
Cheers, - jra
On Thu, Feb 3, 2011 at 1:11 PM, Jay Ashworth jra@baylink.com wrote:
(APNIC runs out of IPv4 space to give to providers somewhere around August, statistically; RIPE in Feb or March 2012, ARIN in July 2012).
ARIN issued the last 5 available /8s to RIRs *today*; we've been talking about it all day on NANOG.
Not exactly. IANA issued the last 5 /8s to RIRs, of which ARIN is one, today. But George is talking about RIR exhaustion, which is still some months away.
His phrasing seemed a bit.. insufficiently clear, to me. That was me, attempting to clarify.
I was trying to explain the situation without trying to braindump the totality of how IP space allocation works structurally, globally, politically, and organizationally, which would have us up all day attempting to get people to understand it all (much less what the acronym list expands to). This list is fortunately not NANOG, and hopefully never will be 8-)
In article 30181972.4621.1296767510190.JavaMail.root@benjamin.baylink.com, Jay Ashworth jra@baylink.com wrote:
----- Original Message -----
From: "River Tarnell" r.tarnell@IEEE.ORG As long as the proxy supports IPv6, it can continue to talk to Apache via IPv4; since WMF's internal network uses RFC1918 addresses, it won't be affected by IPv4 exhaustion.
It might
No, it won't. The internal network IPs (which are used for communication between the proxy and the back-end Apache) are not publicly visible and are completely inconsequential to users.
how would a 6to4NAT affect blocking?
ISP NATs are a separate issue, and might be interesting; if nothing else, as one reason (however small) for ISPs to provide IPv6 to end users. ("Help! I can't edit Wikipedia because my ISP's CGNAT pool was blocked!".)
The general situation with existing ISPs that use transparent proxies is that sometimes users just can't edit. Admins try to document such addresses and avoid blocking them for too long.
(APNIC runs out of IPv4 space to give to providers somewhere around August, statistically; RIPE in Feb or March 2012, ARIN in July 2012).
ARIN issued the last 5 available /8s to RIRs *today*; we've been talking about it all day on NANOG.
Not exactly. IANA issued the last 5 /8s to RIRs, of which ARIN is one, today. But George is talking about RIR exhaustion, which is still some months away.
His phrasing seemed a bit.. insufficiently clear, to me. That was me, attempting to clarify.
Okay. I feel your clarification was not very clear ;-)
ARIN didn't issue any /8s today, IANA did. ARIN was one of the *recipients* of those /8s.
- river.
----- Original Message -----
From: "River Tarnell" r.tarnell@IEEE.ORG
Jay Ashworth jra@baylink.com wrote:
----- Original Message -----
From: "River Tarnell" r.tarnell@IEEE.ORG As long as the proxy supports IPv6, it can continue to talk to Apache via IPv4; since WMF's internal network uses RFC1918 addresses, it won't be affected by IPv4 exhaustion.
It might
No, it won't. The internal network IPs (which are used for communication between the proxy and the back-end Apache) are not publicly visible and are completely inconsequential to users.
how would a 6to4NAT affect blocking?
ISP NATs are a separate issue, and might be interesting; if nothing else, as one reason (however small) for ISPs to provide IPv6 to end users. ("Help! I can't edit Wikipedia because my ISP's CGNAT pool was blocked!".)
You misunderstood me.
If we NAT between the squids and the apaches, will that adversely affect the ability of MW to *know* the outside site's IP address when that's v6?
You're not just changing addresses, you're changing address *families*; is there a standard wrapper for the entire IPv4 address space into v6? (I should know that, but I don't.)
His phrasing seemed a bit.. insufficiently clear, to me. That was me, attempting to clarify.
Okay. I feel your clarification was not very clear ;-)
ARIN didn't issue any /8s today, IANA did. ARIN was one of the *recipients* of those /8s.
Acronym failure; sorry. Yes; Something-vaguely-resembling-IANA issued those last 5 blocks, in keeping with a long-standing sunset policy.
Cheers, -- jra
On Thu, Feb 3, 2011 at 1:41 PM, Jay Ashworth jra@baylink.com wrote:
If we NAT between the squids and the apaches, will that adversely affect the ability of MW to *know* the outside site's IP address when that's v6?
You're not just changing addresses, you're changing address *families*; is there a standard wrapper for the entire IPv4 address space into v6? (I should know that, but I don't.)
There's no reason to NAT between the squid proxies and apaches -- they share a private network, with a private IPv4 address space which is nowhere near being exhausted.
Front-end proxies need to speak IPv6 to the outside world so they can accept connections from IPv6 clients, add the clients' IPv6 addresses to the HTTP X-Forwarded-For header which gets passed to the Apaches, and then return the response body back to the client.
The actual backend Apache servers can happily hum along on IPv4 internally, with no impact on IPv6 accessibility of the site.
-- brion
In article AANLkTikpg8sDNmGWKN2xMW2AGqok1gdYUiOPF7QbMrKm@mail.gmail.com, Brion Vibber brion@pobox.com wrote:
On Thu, Feb 3, 2011 at 1:41 PM, Jay Ashworth jra@baylink.com wrote:
If we NAT between the squids and the apaches, will that adversely affect the ability of MW to *know* the outside site's IP address when that's v6?
You're not just changing addresses, you're changing address *families*; is there a standard wrapper for the entire IPv4 address space into v6? (I should know that, but I don't.)
There's no reason to NAT between the squid proxies and apaches -- they share a private network, with a private IPv4 address space which is nowhere near being exhausted.
I almost said this, but we do have Squids in esams, which has only a /24; and from what I've heard, probably won't be getting any more space, ever. So depending on how many Squids are added in the future, communication between esams and sdtpa could be fun.
(The obvious fix there is to use IPv6 for that...)
- river.
On Thu, Feb 3, 2011 at 1:53 PM, River Tarnell r.tarnell@ieee.org wrote:
In article AANLkTikpg8sDNmGWKN2xMW2AGqok1gdYUiOPF7QbMrKm@mail.gmail.com, Brion Vibber brion@pobox.com wrote:
There's no reason to NAT between the squid proxies and apaches -- they
share
a private network, with a private IPv4 address space which is nowhere near being exhausted.
I almost said this, but we do have Squids in esams, which has only a /24; and from what I've heard, probably won't be getting any more space, ever. So depending on how many Squids are added in the future, communication between esams and sdtpa could be fun.
(The obvious fix there is to use IPv6 for that...)
IIRC the Amsterdam proxies connect to the Tampa proxies on the internet, not directly to the back-end Tampa Apaches on the internal network.
Something NAT-ish actually shouldn't hurt here, since the Amsterdam proxy addresses are whitelisted and thus skipped over for IP tracking -- we'd still have the original requestor's native IPv4 or IPv6 address in the X-Forwarded-For, and it won't matter if we see a particular proxy's IP or the proxy cluster's NAT IP on the other end.
I'm not sure offhand how the cache-clearing signals are working these days, so not sure if that'd be affected (notifications from MediaWiki that particular pages have been updated and their URLs must be purged from cache need to be delivered to all our front-end proxies; this at least used to be done with local-network multicast and a proxy that rebroadcasted the multicast over in Amsterdam; if it still works like that then I don't think it'll be too affected).
-- brion
On Thu, Feb 3, 2011 at 1:45 PM, Brion Vibber brion@pobox.com wrote:
On Thu, Feb 3, 2011 at 1:41 PM, Jay Ashworth jra@baylink.com wrote:
If we NAT between the squids and the apaches, will that adversely affect the ability of MW to *know* the outside site's IP address when that's v6?
You're not just changing addresses, you're changing address *families*; is there a standard wrapper for the entire IPv4 address space into v6? (I should know that, but I don't.)
There's no reason to NAT between the squid proxies and apaches -- they share a private network, with a private IPv4 address space which is nowhere near being exhausted.
Front-end proxies need to speak IPv6 to the outside world so they can accept connections from IPv6 clients, add the clients' IPv6 addresses to the HTTP X-Forwarded-For header which gets passed to the Apaches, and then return the response body back to the client.
The actual backend Apache servers can happily hum along on IPv4 internally, with no impact on IPv6 accessibility of the site.
XFF mode forwarding seems to make the problem pretty much go away, yes.
Thanks for confirming that's what's in use.
On Thu, Feb 3, 2011 at 4:45 PM, Brion Vibber brion@pobox.com wrote:
Front-end proxies need to speak IPv6 to the outside world so they can accept connections from IPv6 clients, add the clients' IPv6 addresses to the HTTP X-Forwarded-For header which gets passed to the Apaches, and then return the response body back to the client.
Interesting. Is there a standard for using IPv6 inside X-Forwarded-For headers? I would think you'd need a new header altogether.
(Yes, this is just used internally so it doesn't matter, but I'm still curious.
In article AANLkTi=nsymTRLv7dWrpiXJ-wNrpJkVgwYiXs+ZJcJiE@mail.gmail.com, Anthony wikimail@inbox.org wrote:
Is there a standard for using IPv6 inside X-Forwarded-For headers?
There is no standard for X-Forwarded-For at all.
I would think you'd need a new header altogether.
Since there's nothing to say what can and can't be put in an XFF header, the existing header works fine:
X-Forwarded-For: 2a01:348:56:0:214:4fff:fe4a:ae17, 77.75.105.169
(That would be for an request from an IPv6 client, through two proxies, the first of which connected to the second via IPv4.)
- river.
On Thu, Feb 3, 2011 at 5:10 PM, River Tarnell r.tarnell@ieee.org wrote:
In article AANLkTi=nsymTRLv7dWrpiXJ-wNrpJkVgwYiXs+ZJcJiE@mail.gmail.com, Anthony wikimail@inbox.org wrote:
Is there a standard for using IPv6 inside X-Forwarded-For headers?
There is no standard for X-Forwarded-For at all.
Not even a de-facto one?
On Thu, Feb 3, 2011 at 2:14 PM, Anthony wikimail@inbox.org wrote:
On Thu, Feb 3, 2011 at 5:10 PM, River Tarnell r.tarnell@ieee.org wrote:
In article <AANLkTi=nsymTRLv7dWrpiXJ-wNrpJkVgwYiXs+ZJcJiE@mail.gmail.comnsymTRLv7dWrpiXJ-wNrpJkVgwYiXs%2BZJcJiE@mail.gmail.com , Anthony wikimail@inbox.org wrote:
Is there a standard for using IPv6 inside X-Forwarded-For headers?
There is no standard for X-Forwarded-For at all.
Not even a de-facto one?
http://en.wikipedia.org/wiki/X-Forwarded-For
-- brion
In article 9259756.4629.1296769269783.JavaMail.root@benjamin.baylink.com, Jay Ashworth jra@baylink.com wrote:
----- Original Message -----
From: "River Tarnell" r.tarnell@IEEE.ORG Jay Ashworth jra@baylink.com wrote:
how would a 6to4NAT affect blocking?
ISP NATs are a separate issue, and might be interesting[...]
You misunderstood me.
If we NAT between the squids and the apaches, will that adversely affect the ability of MW to *know* the outside site's IP address when that's v6?
No, since the client IP is passed via the XFF header. (In any case, putting NAT there doesn't seem very likely to me.)
- river.
On Thu, Feb 3, 2011 at 1:11 PM, Jay Ashworth jra@baylink.com wrote:
----- Original Message -----
From: "River Tarnell" r.tarnell@IEEE.ORG
It doesn't matter if Apache supports IPv6, since the Internet-facing HTTP servers for wikis are reverse proxies, either Squid or Varnish. I believe the version of Squid that WMF is using doesn't support IPv6.
Oh, of course.
As long as the proxy supports IPv6, it can continue to talk to Apache via IPv4; since WMF's internal network uses RFC1918 addresses, it won't be affected by IPv4 exhaustion.
It might; how would a 6to4NAT affect blocking?
It's not really a 6to4 NAT per se - it's a 6to4 application level proxy. The question is, what does Squid hand off to Apache via a IPv4 back end connection if the front end connection is IPv6.
Which, frankly, I have no idea (and am off investigating...).
On Thu, Feb 3, 2011 at 1:21 PM, George Herbert george.herbert@gmail.com wrote:
On Thu, Feb 3, 2011 at 1:11 PM, Jay Ashworth jra@baylink.com wrote:
----- Original Message -----
From: "River Tarnell" r.tarnell@IEEE.ORG
It doesn't matter if Apache supports IPv6, since the Internet-facing HTTP servers for wikis are reverse proxies, either Squid or Varnish. I believe the version of Squid that WMF is using doesn't support IPv6.
Oh, of course.
As long as the proxy supports IPv6, it can continue to talk to Apache via IPv4; since WMF's internal network uses RFC1918 addresses, it won't be affected by IPv4 exhaustion.
It might; how would a 6to4NAT affect blocking?
It's not really a 6to4 NAT per se - it's a 6to4 application level proxy. The question is, what does Squid hand off to Apache via a IPv4 back end connection if the front end connection is IPv6.
Which, frankly, I have no idea (and am off investigating...).
Q: Are we doing tproxy between the squids and apache servers?
That's the obvious not-supported situation with Squid and IPv6 with IPv4 backends.
(That would be solved by adding IPv6 addresses to the Apaches, however).
In article AANLkTi=OnSreaXMi3Gc+0==TzoQ1jfiX63xrkthv6bKr@mail.gmail.com, George Herbert george.herbert@gmail.com wrote:
Q: Are we doing tproxy between the squids and apache servers?
No. But since you mention it, LVS (Linux kernel-level load balancer) is used for load balancing, for both Squid and Apache. LVS supports IPv6, so that shouldn't be an issue.
(That would be solved by adding IPv6 addresses to the Apaches, however).
That would be another way to do it. I don't know what the plan is; my only point originally was that Apache doesn't actually need to know/care about IPv6.
- river.
On Thu, Feb 3, 2011 at 1:35 PM, River Tarnell r.tarnell@ieee.org wrote:
In article AANLkTi=OnSreaXMi3Gc+0==TzoQ1jfiX63xrkthv6bKr@mail.gmail.com, George Herbert george.herbert@gmail.com wrote:
Q: Are we doing tproxy between the squids and apache servers?
No. But since you mention it, LVS (Linux kernel-level load balancer) is used for load balancing, for both Squid and Apache. LVS supports IPv6, so that shouldn't be an issue.
(That would be solved by adding IPv6 addresses to the Apaches, however).
That would be another way to do it. I don't know what the plan is; my only point originally was that Apache doesn't actually need to know/care about IPv6.
As Jay pointed out - handling of blocks (and logins) is an issue (at least, strongly potentially). But without knowing which shaped bricks are in use...
In article AANLkTinQPPu_j=0EmUAF2xoJTHQSxdLUW0btGgU8zvjZ@mail.gmail.com, George Herbert george.herbert@gmail.com wrote:
It's not really a 6to4 NAT per se - it's a 6to4 application level proxy. The question is, what does Squid hand off to Apache via a IPv4 back end connection if the front end connection is IPv6.
I don't think it's useful to think of it in these terms (6to4 anything). All it is is an HTTP proxy; it receives one HTTP request from a client, then open a new connection itself to a web server and sends the same request, then sends the reply back. Whether the client connection comes via IPv6 has no impact on the backend connection, and vice versa.
Here's a diagram:
request client ------------> proxy IPv6
request proxy -----------> backend IPv4
response proxy <----------- backend IPv4
response client <------------ proxy IPv6
- river.
----- Original Message -----
From: "George Herbert" george.herbert@gmail.com
It might; how would a 6to4NAT affect blocking?
It's not really a 6to4 NAT per se - it's a 6to4 application level proxy. The question is, what does Squid hand off to Apache via a IPv4 back end connection if the front end connection is IPv6.
Which, frankly, I have no idea (and am off investigating...).
I rarely have answer, but I do try to ask good questions.
And yes, NAT was a poor choice of terms.
Cheers, -- jra
On Thu, Feb 3, 2011 at 1:05 PM, River Tarnell r.tarnell@ieee.org wrote:
Does any useful discussion still take place on that list?
- river.
I don't know; did any ever? 8-)
It doesn't matter if Apache supports IPv6, since the Internet-facing HTTP servers for wikis are reverse proxies, either Squid or Varnish. I believe the version of Squid that WMF is using doesn't support IPv6.
As long as the proxy supports IPv6, it can continue to talk to Apache via IPv4; since WMF's internal network uses RFC1918 addresses, it won't be affected by IPv4 exhaustion.
Ah, yes. That problem. "We're" using that hacked up Squid 2.7, right?
I'm not as involved as I was a couple of years ago, but I was running a large Squid 3.0 and experimental 3.1 site for about 3 years.
Squid wiki says we need any 3.1 release (latest have some significant bugfixes):
http://wiki.squid-cache.org/Features/IPv6
In article AANLkTikBWLOYHZy4jLN6jwkpHFjoTGO-PpqxfwuPf1EZ@mail.gmail.com, George Herbert george.herbert@gmail.com wrote:
It doesn't matter if Apache supports IPv6, since the Internet-facing HTTP servers for wikis are reverse proxies, either Squid or Varnish. I believe the version of Squid that WMF is using doesn't support IPv6.
Ah, yes. That problem. "We're" using that hacked up Squid 2.7, right?
As far as I know, yes. I don't know if the plan is to update to a newer Squid, or to switch to Varnish entirely.
http://wikitech.wikimedia.org/view/IPv6_deployment mentions either using another front-end proxy, or upgrading.
- river.
Jay Asworth wrote:
As long as the proxy supports IPv6, it can continue to talk to Apache
via IPv4; since WMF's internal network uses RFC1918 addresses, it won't be affected by IPv4 exhaustion.
It might; how would a 6to4NAT affect blocking?
If the XFF header is right, from mediawiki POV an IPv4 internal NAT is no different than being a native IPv6 server.
George Herbert wrote:
On Thu, Feb 3, 2011 at 1:05 PM, River Tarnell r.tarnell@ieee.org wrote:
Does any useful discussion still take place on that list?
- river.
I don't know; did any ever? 8-)
It doesn't matter if Apache supports IPv6, since the Internet-facing HTTP servers for wikis are reverse proxies, either Squid or Varnish. I believe the version of Squid that WMF is using doesn't support IPv6.
As long as the proxy supports IPv6, it can continue to talk to Apache via IPv4; since WMF's internal network uses RFC1918 addresses, it won't be affected by IPv4 exhaustion.
Ah, yes. That problem. "We're" using that hacked up Squid 2.7, right?
They are two different branches. Seems WMF will need to move from squid package to squid3.
It is running with 9 custom patches. I thought more of them would have been included upstream.
02-dfl-error-dir.dpatch Trivial. But ./configure --datadir=/path should be used instead. 10-nozerobufs.dpatch It's probably merged in, since we got it from upstream. 20-wikimedia-errors.dpatch Easy. It uses language codes now. 21-nomangle-requestCC.dpatch Simple to patch. 21-nomanglerequestheaders.dpatch No longer needed. squid3 has a configuration option for this. 22-normalize-requestAE.dpatch It's easy to strip the other encodings. I'd drop the first piece. 22-udplog.dpatch Candidate for manual patching. parse_sockaddr_in_list is now parse_IpAddress_list_token, remember that parse_sockaddr is made from the piece taken from the previous function. 25-coss-remove-swap-log.dpatch Not applicable. No COSS support in squid3 23-variant-invalidation.dpatch 26-vary_options.dpatch Need to be reimplemented.
On 04/02/11 08:13, George Herbert wrote:
On Thu, Feb 3, 2011 at 1:05 PM, River Tarnell r.tarnell@ieee.org wrote:
Does any useful discussion still take place on that list?
- river.
I don't know; did any ever? 8-)
It doesn't matter if Apache supports IPv6, since the Internet-facing HTTP servers for wikis are reverse proxies, either Squid or Varnish. I believe the version of Squid that WMF is using doesn't support IPv6.
As long as the proxy supports IPv6, it can continue to talk to Apache via IPv4; since WMF's internal network uses RFC1918 addresses, it won't be affected by IPv4 exhaustion.
Ah, yes. That problem. "We're" using that hacked up Squid 2.7, right?
I'm not as involved as I was a couple of years ago, but I was running a large Squid 3.0 and experimental 3.1 site for about 3 years.
Squid wiki says we need any 3.1 release (latest have some significant bugfixes):
It's not necessary for the main Squid cluster to support IPv6 in order to serve the main website via IPv6.
The amount of IPv6 traffic will presumably be very small in the short term. We can just set up a single proxy server in each location (Tampa and Amsterdam), and point all of the relevant AAAA records to it. All the proxy has to do is add an X-Forwarded-For header, and then forward the request on to the relevant IPv4 virtual IP. The request will then be routed by LVS to a frontend squid.
MediaWiki already supports IPv6, so that's it, that's all you have to do. It would be trivial, except for the need to handle complaints from users and ISPs with broken IPv6 routing.
What will be more difficult is setting up IPv6 support for all our miscellaneous services: Bugzilla, OTRS, Subversion, mail, etc. Many of those will be harder to set up than the main website.
-- Tim Starling
On Thu, Feb 3, 2011 at 4:32 PM, Tim Starling tstarling@wikimedia.org wrote:
On 04/02/11 08:13, George Herbert wrote:
[...] Ah, yes. That problem. "We're" using that hacked up Squid 2.7, right?
I'm not as involved as I was a couple of years ago, but I was running a large Squid 3.0 and experimental 3.1 site for about 3 years.
Squid wiki says we need any 3.1 release (latest have some significant bugfixes):
It's not necessary for the main Squid cluster to support IPv6 in order to serve the main website via IPv6.
The amount of IPv6 traffic will presumably be very small in the short term. We can just set up a single proxy server in each location (Tampa and Amsterdam), and point all of the relevant AAAA records to it. All the proxy has to do is add an X-Forwarded-For header, and then forward the request on to the relevant IPv4 virtual IP. The request will then be routed by LVS to a frontend squid.
MediaWiki already supports IPv6, so that's it, that's all you have to do. It would be trivial, except for the need to handle complaints from users and ISPs with broken IPv6 routing.
Broken IPv6 routing will be evident to the providers and users, because nothing will work. I would expect few complaints to us... (perhaps naively...)
As a general question - is there any reason not to move to Squid 3.1 and just be done with it that way?
What will be more difficult is setting up IPv6 support for all our miscellaneous services: Bugzilla, OTRS, Subversion, mail, etc. Many of those will be harder to set up than the main website.
Yes. 80/20 rule...
In article AANLkTikS7Kcenbz94UjhfOYi6usRGSSf5VBrQCpK=V+J@mail.gmail.com, George Herbert george.herbert@gmail.com wrote:
Broken IPv6 routing will be evident to the providers and users, because nothing will work. I would expect few complaints to us... (perhaps naively...)
This is actually more of an issue than you might think... many users *already* have broken IPv6 connectivity[0], and it's only going to get worse with early adopters, since most (IPv4) users won't notice the problem.
That might not be too bad, except most users tend not to report problems, and just assume the site is broken.
Of course, in a couple of years when more sites support IPv6, broken connectivity will be much more obvious, and users will just complain to their ISP.
- river.
[0] Several years back I gave en.wikipedia.org an AAAA record for testing. (In hindsight, that was probably a bad idea, but anyway.) One of the users who was unable to access the site, and couldn't work out why, was another Wikimedia sysadmin.
On 04/02/11 11:39, George Herbert wrote:
Broken IPv6 routing will be evident to the providers and users, because nothing will work. I would expect few complaints to us... (perhaps naively...)
There will be complaints. That's what World IPv6 Day is for, besides raising awareness: it's a day when complaints can be handled in a streamlined way.
Speaking of which, I don't see us on this list:
http://isoc.org/wp/worldipv6day/participants/
As a general question - is there any reason not to move to Squid 3.1 and just be done with it that way?
Upgrading our Squid cluster is complex and time-consuming. It would be a lot of trouble to go to just for IPv6 support.
-- Tim Starling
On Thu, Feb 3, 2011 at 6:29 PM, Tim Starling tstarling@wikimedia.org wrote:
On 04/02/11 11:39, George Herbert wrote:
Broken IPv6 routing will be evident to the providers and users, because nothing will work. I would expect few complaints to us... (perhaps naively...)
There will be complaints. That's what World IPv6 Day is for, besides raising awareness: it's a day when complaints can be handled in a streamlined way.
Speaking of which, I don't see us on this list:
http://isoc.org/wp/worldipv6day/participants/
As a general question - is there any reason not to move to Squid 3.1 and just be done with it that way?
Upgrading our Squid cluster is complex and time-consuming. It would be a lot of trouble to go to just for IPv6 support.
I would recommend upgrading the Squid cluster because it's run on a very significantly old version of the software, lacks several years worth of general patches and maintenance, and because it's not THAT big a deal. As I mentioned earlier in thread, I spent several years running Squid (at the time, 3.0-stablevarious and 3.1 beta tests) at a large site, and it didn't take that much time and effort despite working actively with Amos and others on what turned out to be an uninitialized buffer problem for over a year and having to compile, tune, and seriously test all the versions from 3.0-STABLE3 through ... 19, it looks like. It was perhaps 20% of my total work for about 3 years, and would have been far less had it not been for the one persistent bug (going from the prior 2.6 squids to 3.0 took about 3 months of me 1/4 time-ish). Performance was noticeably better with 3.0 vs 2.6 and 2.7.
Avoidance of obsolete version software rot is a key operations technique. My current main commercial consulting customer has 5 years-past-end-of-support key enterprise infrastructure software that they don't even quite know how to upgrade, it's so old now. Don't let your versions get that old...
Yes, 2.7 is still getting necessary Squid project patches, latest to STABLE9 in March 2010, but still. It's old 8-)
I would recommend upgrading the Squid cluster because it's run on a very significantly old version of the software, lacks several years worth of general patches and maintenance, and because it's not THAT big a deal. As I mentioned earlier in thread, I spent several years running Squid (at the time, 3.0-stablevarious and 3.1 beta tests) at a large site, and it didn't take that much time and effort despite working actively with Amos and others on what turned out to be an uninitialized buffer problem for over a year and having to compile, tune, and seriously test all the versions from 3.0-STABLE3 through ... 19, it looks like. It was perhaps 20% of my total work for about 3 years, and would have been far less had it not been for the one persistent bug (going from the prior 2.6 squids to 3.0 took about 3 months of me 1/4 time-ish). Performance was noticeably better with 3.0 vs 2.6 and 2.7.
Well, by all means, add our patches in to the newer version, and provide a source package.
Avoidance of obsolete version software rot is a key operations technique. My current main commercial consulting customer has 5 years-past-end-of-support key enterprise infrastructure software that they don't even quite know how to upgrade, it's so old now. Don't let your versions get that old...
Yes, 2.7 is still getting necessary Squid project patches, latest to STABLE9 in March 2010, but still. It's old 8-)
Our plan is to eventually move away from squid and to varnish. Upgrading squid really isn't amazingly high on our priority list right now.
Respectfully,
Ryan Lane
----- Original Message -----
From: "Tim Starling" tstarling@wikimedia.org
It's not necessary for the main Squid cluster to support IPv6 in order to serve the main website via IPv6.
The amount of IPv6 traffic will presumably be very small in the short term. We can just set up a single proxy server in each location (Tampa and Amsterdam), and point all of the relevant AAAA records to it. All the proxy has to do is add an X-Forwarded-For header, and then forward the request on to the relevant IPv4 virtual IP. The request will then be routed by LVS to a frontend squid.
That's so obvious I'm embarassed I didn't think of it.
Given how big we are, though "very" small may be most websites "medium traffic day". :-)
Cheers, -- jra
On Thu, Feb 3, 2011 at 12:58 PM, Jay Ashworth jra@baylink.com wrote:
----- Original Message -----
From: "George Herbert" george.herbert@gmail.com
I just checked and determined that there appear to be no AAAA records yet for the WMF servers.
I have to admit to having been negligent in examining the IPv6 readiness of the Mediawiki software. Is it generally working and ready to go on IPv6?
Is Apache? That's the base question, is it not? I think the answer is yes.
The importance of this is going to be high in the Asia-Pacific region within a few months: http://www.potaroo.net/tools/ipv4/rir.jpg
(APNIC runs out of IPv4 space to give to providers somewhere around August, statistically; RIPE in Feb or March 2012, ARIN in July 2012).
ARIN issued the last 5 available /8s to RIRs *today*; we've been talking about it all day on NANOG.
In each region, ISPs then will start running out of IPv4 to hand out within a month to three months of the registry exhaustion.
We have a few months, but by the end of 2012, any major site needs to be serving IPv6.
Out of curiosity, is anyone from the Foundation on the NANOG mailing lists?
Oh yeah; that's what triggered this. :-)
Cheers, -- jra
Yes, I know YOU are Jay, and presumably I count as I was on NANOG in 1995, but I was asking about WMF staff / ops department.
I believe the WMF intends to participate in World IPv6 Day [1], additionally they publish some IPv6 statistics [2]. See also the IPv6 deployment page [3].
[1] http://isoc.org/wp/worldipv6day/ [2] http://ipv6and4.labs.wikimedia.org/ [3] http://wikitech.wikimedia.org/view/IPv6_deployment
Robert
On 2011-02-03, George Herbert wrote:
I just checked and determined that there appear to be no AAAA records yet for the WMF servers.
I have to admit to having been negligent in examining the IPv6 readiness of the Mediawiki software. Is it generally working and ready to go on IPv6?
Does the Foundation have a IPv6 support plan ready to go?
The importance of this is going to be high in the Asia-Pacific region within a few months: http://www.potaroo.net/tools/ipv4/rir.jpg
(APNIC runs out of IPv4 space to give to providers somewhere around August, statistically; RIPE in Feb or March 2012, ARIN in July 2012).
In each region, ISPs then will start running out of IPv4 to hand out within a month to three months of the registry exhaustion.
We have a few months, but by the end of 2012, any major site needs to be serving IPv6.
Out of curiosity, is anyone from the Foundation on the NANOG mailing lists?
-- -george william herbert george.herbert@gmail.com
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 3 February 2011 21:04, Robert Leverington robert@rhl.me.uk wrote:
[2] http://ipv6and4.labs.wikimedia.org/ [3] http://wikitech.wikimedia.org/view/IPv6_deployment
Someone actually emailed the press queue today asking if we were participating in IPv6 Day. I passed them those two links and said the issues were under discussion on wikitech-l.
As soon as the sysadmins have some idea what's happening and the likely effects, a techblog post would probably be a good idea - with IPv4 running out, the rest of the world is starting to wonder about this.
- d.
On Thu, Feb 3, 2011 at 3:50 PM, George Herbert george.herbert@gmail.com wrote:
We have a few months, but by the end of 2012, any major site needs to be serving IPv6.
Unlikely. ISPs are just going to start forcing users to use NAT more aggressively, use tunnelling, etc. No residential client is going to be given a connection that's incapable of accessing IPv4-only sites until virtually all sites have switched, which is probably at least a decade from now. They'd (rightfully) cancel their subscription on the grounds that the Internet doesn't work.
Of course, it would be great if we could switch sooner, and I hope we will. But it's not like we'll *need* to.
On Thu, Feb 3, 2011 at 1:53 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Thu, Feb 3, 2011 at 3:50 PM, George Herbert george.herbert@gmail.com wrote:
We have a few months, but by the end of 2012, any major site needs to be serving IPv6.
Unlikely. ISPs are just going to start forcing users to use NAT more aggressively, use tunnelling, etc. No residential client is going to be given a connection that's incapable of accessing IPv4-only sites until virtually all sites have switched, which is probably at least a decade from now. They'd (rightfully) cancel their subscription on the grounds that the Internet doesn't work.
Of course, it would be great if we could switch sooner, and I hope we will. But it's not like we'll *need* to.
You're making assumptions here that the residential ISPs in the US and Asia have stated aren't true...
I'm glad this thread soon got to the point where we realise the problem is on the application layer level.
So what are exactly the implications for blocking and related issues when we will start to see ISP level NATing? 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?
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?)
Will we be needing anon user- and user talk pages for a combination of ISP NAT IP and XFF IP? when ISP level NAT's show up?
kind regards, Martijn.
On Thu, Feb 3, 2011 at 11:01 PM, George Herbert george.herbert@gmail.com wrote:
On Thu, Feb 3, 2011 at 1:53 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Thu, Feb 3, 2011 at 3:50 PM, George Herbert george.herbert@gmail.com wrote:
We have a few months, but by the end of 2012, any major site needs to be serving IPv6.
Unlikely. ISPs are just going to start forcing users to use NAT more aggressively, use tunnelling, etc. No residential client is going to be given a connection that's incapable of accessing IPv4-only sites until virtually all sites have switched, which is probably at least a decade from now. They'd (rightfully) cancel their subscription on the grounds that the Internet doesn't work.
Of course, it would be great if we could switch sooner, and I hope we will. But it's not like we'll *need* to.
You're making assumptions here that the residential ISPs in the US and Asia have stated aren't true...
-- -george william herbert george.herbert@gmail.com
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
On Thu, Feb 3, 2011 at 5:20 PM, River Tarnell r.tarnell@ieee.org wrote:
In article AANLkTim3ht9HXaU3sgwMfu9mPh9Gb2Rx2MiSg3VMCiie@mail.gmail.com, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
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.
But, "supports IPv6" could be as simple as having an http proxy server which sends (fake) IPv6 XFF headers.
By fake, I mean that there's not even a need for the client to actually use that IPv6 address, so long as each user/session gets a different IP within a block controlled by that ISP.
On Thu, Feb 3, 2011 at 5:29 PM, Anthony wikimail@inbox.org wrote:
But, "supports IPv6" could be as simple as having an http proxy server which sends (fake) IPv6 XFF headers.
By fake, I mean that there's not even a need for the client to actually use that IPv6 address, so long as each user/session gets a different IP within a block controlled by that ISP.
And as an added bonus by using these proxies they can be more easily tracked for corporate marketing and government surveillance purposes!
* Martijn Hoekstra martijnhoekstra@gmail.com [Thu, 3 Feb 2011 23:12:27 +0100]:
I'm glad this thread soon got to the point where we realise the problem is on the application layer level.
So what are exactly the implications for blocking and related issues when we will start to see ISP level NATing? 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?
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?)
Will we be needing anon user- and user talk pages for a combination of ISP NAT IP and XFF IP? when ISP level NAT's show up?
I already do something like that with IPv4 in my poll extension. I've noticed how many people are posting from private addresses behind the proxies with internet address, so I record both IP/XFF as anonymous user name (however private IP XFF by default is not recorded, you have to enable it with $wgUsePrivateIPs = true; XFF value becomes a subpage in NS_USER user page. Dmitriy
On Thu, Feb 3, 2011 at 5:01 PM, George Herbert george.herbert@gmail.com wrote:
You're making assumptions here that the residential ISPs in the US and Asia have stated aren't true...
I'm awfully sure the assumption "customers will not pay for an Internet connection that only connects to IPv6 addresses" is true, and will remain true for at least five to ten years. How ISPs deal with it is up to them, but it's not going to be anything that stops customers from accessing IPv4-only sites. Once they have too few IPv4 addresses to assign all customers unique IPv4 addresses, then they'll share IPv4 addresses, such as via NAT -- as well as possibly giving out unique, stable IPv6 addresses.
On Thu, Feb 3, 2011 at 5:02 PM, River Tarnell r.tarnell@ieee.org wrote:
ISPs will probably do this, but I don't think it's right to say they'll *just* do this. In the US, for example, Comcast has been running IPv6 trials for a while, and expects to start giving end-user IPv6 addresses this year.
Yes, but they'll have IPv4 access as well. Comcast's trial is dual-stack, not IPv6-only:
There's not going to be any market for IPv6-only residential connections for the foreseeable future.
On Thu, Feb 3, 2011 at 3:21 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Thu, Feb 3, 2011 at 5:01 PM, George Herbert george.herbert@gmail.com wrote:
You're making assumptions here that the residential ISPs in the US and Asia have stated aren't true...
I'm awfully sure the assumption "customers will not pay for an Internet connection that only connects to IPv6 addresses" is true, and will remain true for at least five to ten years. How ISPs deal with it is up to them, but it's not going to be anything that stops customers from accessing IPv4-only sites. Once they have too few IPv4 addresses to assign all customers unique IPv4 addresses, then they'll share IPv4 addresses, such as via NAT -- as well as possibly giving out unique, stable IPv6 addresses.
On Thu, Feb 3, 2011 at 5:02 PM, River Tarnell r.tarnell@ieee.org wrote:
ISPs will probably do this, but I don't think it's right to say they'll *just* do this. In the US, for example, Comcast has been running IPv6 trials for a while, and expects to start giving end-user IPv6 addresses this year.
Yes, but they'll have IPv4 access as well. Comcast's trial is dual-stack, not IPv6-only:
There's not going to be any market for IPv6-only residential connections for the foreseeable future.
There won't be much choice when the ISPs run out of IPv4 space to allocate new users.
As I said - we'll see it in Asia soon enough, and then the US down the road a bit longer.
In article AANLkTi=EnP2_sY+g2dt_sW0oq8-05_JJCOjgXsdT06J1@mail.gmail.com, George Herbert george.herbert@gmail.com wrote:
On Thu, Feb 3, 2011 at 3:21 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
Yes, but they'll have IPv4 access as well.
There won't be much choice when the ISPs run out of IPv4 space to allocate new users.
Don't underestimate the ability of ISPs to sell really bad service to users who don't know any better. 99% of home users already use NAT for their Internet access; they aren't going to know or care that their ISP is now using CGNAT.
(At least until they get blocked on Wikipedia...)
- river.
On Thu, Feb 3, 2011 at 6:29 PM, George Herbert george.herbert@gmail.com wrote:
There won't be much choice when the ISPs run out of IPv4 space to allocate new users.
As I said - we'll see it in Asia soon enough, and then the US down the road a bit longer.
You mean, when they have so little IPv4 space that they can't even fit all of their customers behind NAT? If they have enough IPv4 addresses at present to give out dedicated addresses to all users, they'll run out of addresses using NAT when they have maybe 10,000 to 100,000 times as many users as now, which seems unlikely to be anytime in the foreseeable future -- especially if traffic starts shifting to IPv6. NAT isn't a cure-all, but it works fine for browsing websites, which is all that directly concerns Wikipedia.
The point remains, websites that are only accessible via IPv4 are not in any danger of becoming unreachable anytime soon by a large number of people.
On Thu, Feb 3, 2011 at 7:02 PM, River Tarnell r.tarnell@ieee.org wrote:
That's what I said. They'll do "this" -- meaning IPv4 with CGNAT -- as well as providing IPv6 access.
Right.
On 04/02/11 00:29, George Herbert wrote: <snip>
There won't be much choice when the ISPs run out of IPv4 space to allocate new users.
It is already the case! Thankfully there is DS-Lite which let you transport v4 over v6. CPE is v6 only on the WAN side, if an IPv4 packet is received on LAN side it is send in tunnel ending up in a big NAT device (on the ISP side).
Makes sens since you have a small pool of v4 address, the solution is easy to implement as long as your end user does not host any services (most internet users anyways).
Wouldn't it be nice to just set up ipv6 a test? Something similar to https://secure.wikimedia.org/ . That way I can just open https://ipv6.wikimedia.org/wikipedia/en/wiki/Main_Page if I want to browse Wikipedia using ipv6.
Maarten
Ps. Of course https://secure6.wikimedia.org/ is even better ;-)
In article AANLkTi=1foHsEOh25Dr+Df2N4DFXj4iKU0SWXg1xXWP=@mail.gmail.com, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Thu, Feb 3, 2011 at 5:02 PM, River Tarnell r.tarnell@ieee.org wrote:
ISPs will probably do this, but I don't think it's right to say they'll *just* do this. In the US, for example, Comcast has been running IPv6 trials for a while, and expects to start giving end-user IPv6 addresses this year.
Yes, but they'll have IPv4 access as well.
That's what I said. They'll do "this" -- meaning IPv4 with CGNAT -- as well as providing IPv6 access.
- river.
In article AANLkTikgM845ZOvSGqpdvq81juHN8Wm3RwZcxvBqN3oX@mail.gmail.com, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
ISPs are just going to start forcing users to use NAT more aggressively, use tunnelling, etc.
ISPs will probably do this, but I don't think it's right to say they'll *just* do this. In the US, for example, Comcast has been running IPv6 trials for a while, and expects to start giving end-user IPv6 addresses this year. So IPv6 for end users is coming, it's just taking longer than it should have.
- river.
wikitech-l@lists.wikimedia.org