IF your machine does not have global IPv6 connectivity, including a globally visible 
IPv6 address, then Chromium will will disable all IPv6 support.

If you want to experiment with ONLY a local host, and not real IPv6 connectivity, 
then you need to start with a special over-ride command-line flag "--enable-ipv6".  
That will force Chromium to support IPv6 resolutions.

The reason for this "feature" is that many LANs appear to mis-handle an IPv6 
resolution attempt, causing GREAT delays.  The solution was (in such cases where 
there was no IPv6 connectivity) to disable IPv6 resolutions.

If you have a globally visible IPv6 address (such as might be procured from a DHCP 
server, or some static allocation), then Chromium *should* support IPv6 connectivity, 
including to your local host.

jar: you seem to have misunderstood the bug report.  The complaint is that
Chrome cannot connect to a URL that contains an IPv6 address literal.

Sorry about my misunderstanding.... re-opening

Yeah, two different bugs if what jar says is correct:

- IPv6 literals are not understood (most important one). See the ipv6.google.com
example and bug title
- Can't use IPv6 when not globally connected with ipv6. I was also puzzled that using
ip6-localhost, which is correctly defined in /etc/hosts, failed to get a connection
while it works perfectly with firefox. Is the resolver bypassing /etc/hosts?

@santiago.gala

We've encountered problems with some LANs, when an attempt is made to resolve an IPv6 
address (and IPv6 is not well supported).  The problem can result in large resolution 
delays..  As a result, we currently disable IPv6 completely when there is no 
interface with an globally visible IPv6 address.  It seemed better to sacrifice the 
ability to set up a private IPv6 localhost, than to cause dramatic performance 
degradation to users that were clueless about this entire issue.  If you, as a 
developer, wish to enable IPv6 so you *can* use a localhost with such an address, 
then you'll need to override our probe, and use --enable-ipv6 as a command line 
argument.  If this happens to cause devastating perf degradation in your external 
browsing, we hope you'll be able to debug the issue.... but it sounds like your LAN 
can deal with this all just fine.

With regard to your detailed example, I don't think we bypass /etc/hosts, rather we 
tell the resolver (when we decide not to use IPv6) to ONLY use IPv4.  That would 
probably cause your IPv6 address in /etc/hosts to be ignored.

Hopefully that makes sense.

Again, sorry for misreading the more important issue in your bug.

(No comment was entered for this change.)

It seems to be working as of 5.0.368.0 (43430) Ubuntu

@santiago.gala: if you think it is an issue with resolving of IPv6 literals, go to:
   chrome://net-internals/hostresolver.hostcache

And paste the resulting entries. (Note that IP literals will have their own entry too, since they get run through 
getaddrinfo() just the same).

I've been doing some fixing on 35050 (make ftp on ipv6 work), and I have found some interesting information in 
the hostcache for ipv6 literals.

I have three machines, let's call them Win, Mac, and Nux.  At Mac, I enter 

http://[Mac]/
ftp://[Nux]/

the host cache (pasted from about:net-internals) now looks like this:

Mac	UNSPECIFIED	2620::1004:1:225:ff:fef2:d881	36600
[Nux]	UNSPECIFIED	net::ERR_NAME_NOT_RESOLVED	-166441
[Mac]	UNSPECIFIED	net::ERR_NAME_NOT_RESOLVED	-25097

(also note, the http request to Mac succeeds, the ftp to Nux fails, and a packet sniffer shows no outbound packets 
whatsoever to Nux).

Do the same thing on Win, and I get slightly different behaviour.  The resolver looks like:

Mac	UNSPECIFIED	2620:0:1004:1:225:ff:fef2:d881	50615
[Nux]	UNSPECIFIED	2620:0:1004:1:21e:c9ff:fe47:43f4	-1011241
[Mac]	UNSPECIFIED	2620:0:1004:1:225:ff:fef2:d881	16302

Notice that the [hostnames in square brackets] resolved on windows?  Interesting!  A packet sniffer running on Nux 
shows an FTP control session start from Win --> Nux, then die when the requesting chrome uses PASV to request a 
transfer, when of course EPSV is right for ipv6.  But that's my issue, not the instant one.

On Linux, things look more like the mac:

Mac	UNSPECIFIED	2620:0:1004:1:225:ff:fef2:d881	6348
[Nux]	UNSPECIFIED	net::ERR_NAME_NOT_RESOLVED	-16703
[Mac]	UNSPECIFIED	net::ERR_NAME_NOT_RESOLVED	-54488

See, the [Hostnames] didn't resolve.

All in all very interesting.  However, in every case, I found ipv6 literals worked fine from my browser as long as I 
didn't use our networks squid proxy server (which sometimes, and unpredictably, broke ipv6).

Regarding comment #9, that is a bug in ftp_network_transaction.cc:

  host = request_->url.host(); 
  port = request_->url.EffectiveIntPort();

Really it should be doing

  host = request_->url.HostNoBrackets();
  port = request_->url.EffectiveIntPort();

(HttpNetworkTransaction is careful to do this, to avoid exactly this problem).

I can fix that issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=43888 

------------------------------------------------------------------------
r43888 | eroman@chromium.org | 2010-04-07 15:41:58 -0700 (Wed, 07 Apr 2010) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/ftp/ftp_network_transaction.cc?r1=43888&r2=43887
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/ftp/ftp_network_transaction_unittest.cc?r1=43888&r2=43887

Make sure to strip the brackets around IPv6 literals when resolving the hostname for FTP.

BUG=39830 (comment #9)
TEST=FtpNetworkTransactionTest.StripBracketsFromIPv6Literals

Review URL: http://codereview.chromium.org/1585022
------------------------------------------------------------------------

(No comment was entered for this change.)

(No comment was entered for this change.)

Not sure if it is related, but I'm seeing something strange lately: while 
disconnected, I can't access localhost, localhost.localdomain or even 127.0.0.1, even 
when there is route and processes listening there. I guess this is a bug, is it? 
getaddrinfo works exactly the same with localhost or 127.0.0.1 either connected or 
disconnected...

# Using python while disconnected with and without AI_CANONNAME
>>> import socket
>>> socket.getaddrinfo("127.0.0.1", 8080, socket.AF_UNSPEC,socket.SOCK_STREAM, 
socket.IPPROTO_TCP)
[(2, 1, 6, '', ('127.0.0.1', 8080))]
>>> socket.getaddrinfo("127.0.0.1", 8080, socket.AF_UNSPEC,socket.SOCK_STREAM, 
socket.IPPROTO_TCP, socket.AI_CANONNAME)
[(2, 1, 6, '127.0.0.1', ('127.0.0.1', 8080))]
>>> socket.getaddrinfo("localhost", 8080, socket.AF_UNSPEC,socket.SOCK_STREAM, 
socket.IPPROTO_TCP)
[(10, 1, 6, '', ('::1', 8080, 0, 0)), (2, 1, 6, '', ('127.0.0.1', 8080))]
>>> socket.getaddrinfo("localhost", 8080, socket.AF_UNSPEC,socket.SOCK_STREAM, 
socket.IPPROTO_TCP, socket.AI_CANONNAME)
[(10, 1, 6, 'kurtz', ('::1', 8080, 0, 0)), (2, 1, 6, '', ('127.0.0.1', 8080))]
>>> socket.getaddrinfo("localhost.localdomain", 8080, 
socket.AF_UNSPEC,socket.SOCK_STREAM, socket.IPPROTO_TCP)
[(2, 1, 6, '', ('127.0.0.1', 8080))]
>>> socket.getaddrinfo("localhost.localdomain", 8080, 
socket.AF_UNSPEC,socket.SOCK_STREAM, socket.IPPROTO_TCP, socket.AI_CANONNAME)
[(2, 1, 6, 'kurtz', ('127.0.0.1', 8080))]

Re #8 I already said that it is working now in #7. I think it got fixed in some change 
between the revision I reported against, 5.0.364.0 (42891) Ubuntu and the revision I 
tested later: 5.0.368.0 (43430)

(No comment was entered for this change.)

Is this fixed, then?

I have a CL pending to fix it: http://codereview.chromium.org/3023048

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=56384 

------------------------------------------------------------------------
r56384 | vandebo@chromium.org | 2010-08-17 10:50:41 -0700 (Tue, 17 Aug 2010) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/predictor_unittest.cc?r1=56384&r2=56383
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_list.cc?r1=56384&r2=56383
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_list.h?r1=56384&r2=56383
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_list_unittest.cc?r1=56384&r2=56383
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=56384&r2=56383
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl_unittest.cc?r1=56384&r2=56383
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mock_host_resolver.cc?r1=56384&r2=56383
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_unittest.cc?r1=56384&r2=56383

Don't resolve IP literals.

For each resolution request this checks to see if this 'host' is a literal ip address.  If so, it synthesises a struct addrinfo and returns it without adding it to the cache.

BUG=39830
TEST=unit tests, new and old

Review URL: http://codereview.chromium.org/3023048
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=56385 

------------------------------------------------------------------------
r56385 | vandebo@chromium.org | 2010-08-17 11:00:02 -0700 (Tue, 17 Aug 2010) | 11 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/predictor_unittest.cc?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_list.cc?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_list.h?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_list_unittest.cc?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl_unittest.cc?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mock_host_resolver.cc?r1=56385&r2=56384
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_unittest.cc?r1=56385&r2=56384

Revert 56384 - Don't resolve IP literals.

For each resolution request this checks to see if this 'host' is a literal ip address.  If so, it synthesises a struct addrinfo and returns it without adding it to the cache.

BUG=39830
TEST=unit tests, new and old

Review URL: http://codereview.chromium.org/3023048

TBR=vandebo@chromium.org
Review URL: http://codereview.chromium.org/3115014
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=56615 

------------------------------------------------------------------------
r56615 | vandebo@chromium.org | 2010-08-18 16:26:51 -0700 (Wed, 18 Aug 2010) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/predictor_unittest.cc?r1=56615&r2=56614
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_list.cc?r1=56615&r2=56614
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_list.h?r1=56615&r2=56614
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/address_list_unittest.cc?r1=56615&r2=56614
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=56615&r2=56614
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl_unittest.cc?r1=56615&r2=56614
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mock_host_resolver.cc?r1=56615&r2=56614

Don't resolve IP literals.

For each resolution request this checks to see if this 'host' is a literal ip address.  If so, it synthesises a struct addrinfo and returns it without adding it to the cache.

BUG=39830
TEST=unit tests, new and old

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=56384

Review URL: http://codereview.chromium.org/3023048
------------------------------------------------------------------------

(No comment was entered for this change.)