Page MenuHomePhabricator

Add basic IPv6 support in core
Closed, ResolvedPublic

Description

I don't know if these are just bugs in 1.4b3 or not yet done but reporting anyway:
As IPv6 is now supported, or at least was (
http://fi.wikipedia.org/w/index.php?title=Toiminnot:Contributions&target=2002:3e8e:71b::3e8e:71b
), there is some problems.

Find (the search box) doesn't redirect IPv6-addresses to appropriate
contributions page, like it does for IPv4-addresses.
http://fi.wikipedia.org/wiki/Toiminnot:Search?search=2002%3A3e8e%3A71b%3A%3A3e8e%3A71b&go=Siirry

The user or user talk page of IPv6-addresses doesn't have link to 'User
contributions'
http://fi.wikipedia.org/wiki/Keskustelu_k%C3%A4ytt%C3%A4j%C3%A4st%C3%A4:2002:3e8e:71b::3e8e:71b


Version: 1.8.x
Severity: normal

Details

Reference
bz1196

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:01 PM
bzimport set Reference to bz1196.
bzimport added a subscriber: Unknown Object (MLST).

river wrote:

This is because the IPv6 support from REL1_3A wasn't merged into REL1_4. I'll
try to have a look at this later if no-one else does.

Changing this bug to feature request: Add IPv6 support

phroziac wrote:

...Additionally, on some configurations on a machine supporting ipv6, normal
ipv4 ips get ipv6 representations, ie "::ffff:4.225.242.191". This causes all
the problems with ipv6 ips.

And, they can't be blocked. a block on "::ffff:4.225.242.191" gives the error
"No such user", instead of seeing it as an IP block. A block on the IP in the
normal format just doesn't affect them.

phroziac wrote:

(In reply to comment #3)
...and, a dirty gross nasty hack that fixed the problem, in
includes/ProxyTools.php, change

$ipchain = array( $_SERVER['REMOTE_ADDR'] );

to

$ipchain = array( str_replace("::ffff:", "",$_SERVER['REMOTE_ADDR']) );

...this is on line 23 on last night's CVS HEAD.

Note that the :-prefixed forms are no longer legal titles, so connecting to
eg localhost over IPv6 makes stuff blow up when the IP username is illegal.

Bumping this from enhancement to normal. Some hosts where the
server listens on IPv6 will break for IPv4-to-IPv6 translated
addresses, which means everybody on the present internet.

guillaume.outters wrote:

In reply to #5:

Adding:

if ( $this->mName{0} == ':' ) {
    $this->mName = 'IPv6'.$this->mName;
}

to getName() in includes/User.php makes it. I didn't try to go further though (no test to search for IPv6::1-including threads, and so on).

  • Bug 8246 has been marked as a duplicate of this bug. ***
  • Bug 8251 has been marked as a duplicate of this bug. ***

Add some IPv6 alternative and convertsion functions

First stab at this.

attachment ipv6.patch ignored as obsolete

Add some IPv6 alternative and convertsion functions

Fix file format.

attachment ipv6.patch ignored as obsolete

Fix some bugs

attachment ipv6.patch ignored as obsolete

Some cleanup

attachment ipv6.patch ignored as obsolete

Use wfBaseConvert()

Added some comments, IsInRange() updated

Attached:

Completed in r20361.

Normal IPv4 user and name blocks are still sane on my test wiki, IPv6 blocks
should work but I don't feel like spoofing around to test that.

robchur wrote:

(In reply to comment #15)

should work but I don't feel like spoofing around to test that.

So it hasn't been tested?

(In reply to comment #16)

So it hasn't been tested?

I've done a lot of testing now (changing some things here and there). By forcing
my IP to be that of a blocked IPv6 one (or in a blocked range), the behavoir
seems correct.

OK, this can closed again. The support was reverted out and added back a while ago.

See http://www.mediawiki.org/wiki/IPv6_support.

A tracking bug might be nice. The all caps stuff does make consistency, but it gives me the willies.