New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 132128 link

Starred by 24 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Aug 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocked on:
issue 223876



Sign in to add a comment

ChromeOS: IPv4-only DNS on IPv6 network

Project Member Reported by quiche@chromium.org, Jun 11 2012

Issue description

Chrome Version: 21.0.1166.1
Chrome OS Version: 2411.0.0
Chrome OS Platform: lumpy
Network info: open wifi

Steps To Reproduce:
1. Boot up
2. Connect lumpy to GoogleGuest
3. Go to chrome://net-internals/#dns
4. Examine "Host resolver -> Default address family"

Expected Result: "UNSPECIFIED"

Actual Result:
"IPV4 (IPv6 disabled) [Enable IPv6]"

How frequently does this problem reproduce? (Always, sometimes, hard to
reproduce?)
Sometimes.

What is the impact to the user, and is there a workaround? If so, what is
it?
Must manually enable IPv6 lookups.

Please provide any additional information below. Attach a screen shot or
log if possible.
https://feedback.corp.google.com/#/Report/309431617?context=ri
 

Comment 1 by quiche@chromium.org, Jun 11 2012

We also have a user report:

Google Chrome   18.0.1025.151 (Official Build 130497) beta
Platform        1660.112.0 (Official Build) beta-channel x86-mario
WebKit  535.19 (@113052)
JavaScript      V8 3.8.9.16
Flash   11.2.31.131
User Agent      Mozilla/5.0 (X11; CrOS i686 1660.112.0) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.151 Safari/535.19

At every boot chrome://net-internals/#dns indicates it is using IPv4
only for name resolution and it's specifically stated that IPv6 is
disabled.  Only A records are chosen when a name has both A and AAAA
RRs.  Clicking the "enable IPv6" button puts it into
ADDRESS_FAMILY_UNSPECIFIED mode, and IPv6 works fine in the browser with
names that have A and AAAA RRs.. until the next boot, then the procedure
is required once again (the setting does not seem to be saved).  This is
in the Chrome browser only - if SSH is executed from the crosh shell,
IPv6 is used every time.
Cc: eroman@chromium.org mmenke@chromium.org

Comment 3 by eroman@chromium.org, Jun 11 2012

Cc: jar@chromium.org
The disabling of IPv6 is being done by a probe in Chrome, which runs the function IPV6Supported() from here:

http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc?view=markup

That function seems to be checking for any interface with an IPv6 address that is up.

My guess is either it isn't finding one, or at the time it runs there isn't one that is up yet.

Jim would know more.

Comment 4 by quiche@chromium.org, Jun 11 2012

Couple questions:
- Is this probe retried automatically?
- Does always using ADDRESS_FAMILY_UNSPECIFIED cause problems on some platforms? (On Linux, I believe the DNS resolver in glibc checks for IPv6 connectivity itself.)

Comment 5 by eroman@chromium.org, Jun 12 2012

> - Is this probe retried automatically?

It is retried whenever Chrome detects a "network change". Which basically means whenever an interface's IP address changes.

> - Does always using ADDRESS_FAMILY_UNSPECIFIED cause problems on some platforms?

Jim investigated this and found that there were latency problems (particularly on Linux) due to issues like the resolver waiting for AAAA and yet no possibility of ever connecting to IPv6 addresses. I don't have the details on this though.
Labels: Internals-Network-DNS

Comment 7 by jar@chromium.org, Jun 12 2012

It has been a while.... but as I recall, the OS tends to break this request
into two parts, one for IPv4, and one for IPv6 (re: AAAA records).  At a
minimum, this <sadly> guarantees that our resolution time is the max of two
distinct resolutions  In the case of some OSs, these two requests are
actually serialized, so it is worse that the max of two random variables.
Some older routers (intermediate resolvers) (as I recall) don't respond
well (at all?) to requests for AAAA.  The OS needs responses from both
requests, or a lengthily(?) timeout, before it proceeds.

The fact that we ended up with the current system suggests that it is
uncommon to have an IPv6 adress on an interface, if you don't have IPv6
support.

...but that was then... and we should probably have a fresh look again as
IPv6 becomes more usable (and more used).

Jim

Comment 8 by szym@chromium.org, Jun 12 2012

Assuming HostResolverImpl did not receive SetDefaultAddressFamily, it will restart IPv6ProbeJob in response to OnIPAddressChanged. Testing for IPV6 addresses using getifaddrs is the basic way glibc tests for IPv6 support. The problem might be that we are not detecting address change. I am currently working on improving address tracking on Linux. It will also provide a more reliable (RTNETLINK) way of checking for IPv6 support.

Can you confirm if network change is detected (it's logged in chrome://net-internals/#events)?

Hi - 

(I'm the one who originally reported this issue)

chrome://net-internals/#events displays no events that indicate a network change.  At least, nothing that is obvious.  The steps I took to test this are:

1) Boot Cr-48.
2) Log in (Wi-Fi connects at login screen)
3) Load a page or two.
4) Navigate to chrome://net-internals/#events
5) Navigate to chrome://net-internals/#dns (just to check it's reverted back to disabling IPv4, which it has)

Wi-Fi network provides IPv4+IPv6 (IPv4 provided by DHCP, IPv6 provided by SLAAC).

If there is another sequence of steps you believe would be more helpful, please let me know.

Also, I am now running the following:

Google Chrome: 20.0.1132.22 (Official Build 139714) beta
Platform: 2268.42.0 (Official Build) beta-channel x86-mario

- Mark
#7: I did confirm that IsIPv6Supported filters out link-local IPv6 address bindings, so it should be a rare-ish event that this happens. I can look at the histograms as well.

#9: Given the sequence of events, it's possible that the network change events had already occurred by the time you navigated to chrome://net-internals#events. The net-internals page only records events that happens while it is open. Could you navigate to the net-internals page, disconnect from the wireless access point, and reconnect?
Upon reconnecting to Wi-Fi, the event NETWORK_IP_ADDRESSES_CHANGED is indeed recorded in chrome://net-internals#events along with PROXY_CONFIG_CHANGED (probably irrelevant - I don't have an active proxy server configured).

- Mark

Comment 12 by jar@chromium.org, Jun 14 2012

FWIW: I took a look at our histogram data, and the difference in
performance when using UNSPEC (asking for an IPv6 and IPv4 address) vs IPv4
is quite significant..

This data includes all lookups, including those which come out of the local
OS cache, which is why the durations are smaller than looking at "Network
resolution times."  It might also be the case that there is additional OS
cache pressure caused by doing two (both IPv4 and v6) resolutions), as well
as cache pressure on nearby resolvers to maintain both resolutions, but I
just don't know.

I looked at the currently dominant Windows and Mac versions (first chart is
Windows, second is Mac).  Note that this is sadly a biased sample, as it is
not controlled, and simply shows what a user is using, and what resolution
times they encounter.  I will note that each chart is based on many
millions of samples (collected in a day), so I think the data is pretty
broad, even if it has some bias.  It is IMO a bit surprising to hear that
folks that have IPv6 capable environments have worse resolution times....
but it is certainly plausible that geeks with fast systems have "tuned"
their systems by precluding IPv6 support :-/.

Looking at the medians "Value" columns, windows drops from 36ms down to
32ms, avoiding a 12.61%,cost,  while the mac drops from 43ms to 26ms,
avoiding 66% additional cost..

Looking at the 90th percentiles, in the "Value" columns, windows drops from
946ms to 871ms, or 9% cost, while Mac drops from 455ms to 217ms, or about
110% cost.

Using a trimmed mean, which includes all samples up-to-and-including a
given percentile, we see the following in the ~Avg columns.

For the 50% trimmed mean, on Widows, resolution (strongly biased by a
fasted local caching) changed from 11ms to 8ms, avoiding an 32% cost, while
on Mac it changed from 12ms to 7ms, avoiding a 73% cost.

To get a good look at the overall mean, without the noise that is seen in
the tail end of any distribution, we can look at the 95% trimmed mean.
 This includes all but 5% of the samples (the more questionable outliers(?)
are discarded).

For the 95% trimmed mean, in Windows, resolution changed from 86ms to 77ms,
to avoid an 11% cost, while on Mac, it changed from 128ms to 50ms, avoiding
a 154% cost.

I'd at least conclude that Mac was serializing the pairs of resolutions,
and that is probably what is driving the exaggerated cost of using
FAMILY_UNSPEC (both IPv4 and v6). Windows is probably firing off
the resolutions in parallel, and is "merely" incurring the wrath of the
max-of-two-random-variables, which has a much larger mean than either of
the component times, but nowhere near dobule (as seen on Mac).



19.0.1084.52-WDNS.ResolveSuccess_FAMILY_UNSPECDNS.ResolveSuccess_FAMILY_IPV4Delta
SavingsCutoffValueMin Avg~AvgMax AvgValueMin Avg~AvgMax AvgValue%~Avg%50.00%
36.6010.1310.5911.0532.507.6858.0098.3334.10012.61%2.58332.25%60.00%56.45
15.5316.4117.2851.5112.8313.5414.244.9489.61%2.87121.21%70.00%89.1022.75
24.1625.5681.9419.6820.8822.097.1608.74%3.27315.67%80.00%157.133.6535.87
38.10143.629.7931.7533.7113.549.43%4.12212.98%90.00%373.054.7558.5862.41
342.249.3452.7856.2230.799.00%5.79310.97%95.00%945.980.2886.0791.86871.1
72.4177.6282.8374.858.59%8.45010.89%98.00%2103115.6124.1132.61749103.8111.4
119.1354.420.27%12.6611.36%


19.0.1084.56-MDNS.ResolveSuccess_FAMILY_UNSPECDNS.ResolveSuccess_FAMILY_IPV4Delta
SavingsCutoffValueMin Avg~AvgMax AvgValueMin Avg~AvgMax AvgValue%~Avg%50.00%
42.8111.5112.1112.7025.766.7206.9817.24217.0566.17%5.12673.42%60.00%75.29
18.3719.4720.5737.8810.4911.0011.5137.4198.75%8.47277.04%70.00%195.231.73
33.8335.9355.8615.1115.9716.83139.4249.46%17.86111.84%80.00%356.363.6068.15
72.7092.3721.5122.8424.17264.0285.76%45.31198.40%90.00%454.697.61104.8111.9
216.833.5835.8238.06237.7109.66%68.94192.47%95.00%760.5119.7128.6137.4468.4
47.2350.5053.78292.162.37%78.05154.54%98.00%1407145.5156.4167.2113867.87
72.7377.60268.323.57%83.62114.97%

Comment 13 by szym@chromium.org, Jun 14 2012

Mark,
It'd be very useful to know the exact output of the IPv6 probe job. To find out, do the following: 

1) Navigate to chrome://histograms/ find Net.IPv6Status and copy the histogram data. It might look like this:

Histogram: Net.IPv6Status recorded 1 samples, average = 4.0 (flags = 0x1)
0  ... 
4  ------------------------------------------------------------------------O (1 = 100.0%) {0.0%}
5  ... 

2) Then connect to the network that supports IPv6. Once it has connected, wait a few seconds, refresh the chrome://histogram tab, and copy the updated data.

3) Paste the histogram data here.

Just chiming in to clarify things so people don't get confused by misleading statements.

@jar: your hypotheses about the serialization vs parallelization of A and AAAA queries on Win vs OS X systems is off. We can discuss this offline if you want, so we don't hijack this thread, since comment #12 seems like a digression from the current issue.

Comment 15 by jar@google.com, Jun 14 2012

Posting in comment 12 was meant to be a response to comment 5, trying to clear comment about platform impact.

...and the table I posted got trashed in the translation to ASCII for posting :-(.  Only folks subscribed to this bug have much of a chance of reading the (raw) data <sigh>

willchan: FWIW: My recollection was that Windows or linux serialized... and Mac was smart and parallelized... but the (contradictory?) data sure pushed me tho other way.  I look forward to a better offline explanation of the data. <since it seems slightly off-topic>.
Hi - 

Sorry for the delay.  From chrome://histograms/, right after a boot, the Net.IPv6Status shows the following:

Histogram: Net.IPv6Status recorded 1 samples, average = 3.0 (flags = 0x1)
0  ... 
3  ------------------------------------------------------------------------O (1 = 100.0%) {0.0%}
4  ... 

After disconnecting Wi-Fi, then re-connecting, waiting a few seconds, then reloading the chrome://histograms/ page, it's still the following:

Histogram: Net.IPv6Status recorded 1 samples, average = 3.0 (flags = 0x1)
0  ... 
3  ------------------------------------------------------------------------O (1 = 100.0%) {0.0%}
4  ... 

Hope this helps!

- Mark

Comment 17 by jar@chromium.org, Jun 18 2012

re: comment 16 showing histograms

There are two distinct histograms.  One records the first test ever done during the process, and the other shows all retests.  The two histograms are:

Net.IPv6Status
Net.IPv6Status_retest

You can see them both by visiting:
about:histograms/IPv6Status

Please check to see if the _retest variant gets additional samples after you toggle the wifi connection.

Testing on my desktop... disconnecting the cable seemed to induce a retest.... but I had gmail running... which may have helped to force use of the network.
re: Histograms

Alright, let's try this again.  I repeated the same steps.  Right after ChromeOS boot & connecting to Wi-Fi:

Histogram: Net.IPv6Status recorded 1 samples, average = 3.0 (flags = 0x1)
0  ... 
3  ------------------------------------------------------------------------O (1 = 100.0%) {0.0%}
4  ... 


Histogram: Net.IPv6Status_retest recorded 2 samples, average = 3.0 (flags = 0x1)
0  ... 
3  ------------------------------------------------------------------------O (2 = 100.0%) {0.0%}
4  ... 

After re-connecting to Wi-Fi:


Histogram: Net.IPv6Status recorded 1 samples, average = 3.0 (flags = 0x1)
0  ... 
3  ------------------------------------------------------------------------O (1 = 100.0%) {0.0%}
4  ... 


Histogram: Net.IPv6Status_retest recorded 5 samples, average = 3.0 (flags = 0x1)
0  ... 
3  ------------------------------------------------------------------------O (5 = 100.0%) {0.0%}
4  ... 

One data point that might be helpful (I just observed it).  If Wi-Fi connects when sitting at the login screen before logging in, IPv6 is never enabled, from what I can tell.  However, if I login before Wi-Fi connects (or just have Wi-Fi disabled until logging on), *sometimes* IPv6 will be enabled (ie, address family UNSPECIFIED) automatically.  This seems like a timing thing, but I'm not sure.  Figured I'd throw it out there!

- Mark

Comment 19 by szym@chromium.org, Jun 20 2012

Thanks for the further detail, Mark. This result (3) is IPV6_GLOBAL_ADDRESS_MISSING which means that all IPv6 addresses enumerated are either loopback or link-local (also mentioned in #10). 

Only now I noticed that you said that IPv6 address is provided by SLAAC. It's unsurprising then that the address scope is link-local. I am guessing that ssh uses IPv6 when connecting to a host on LAN, but I suspect it will not work with a remote IPv6 host.

If that is the case, it seems that Chrome's disabling of IPv6 DNS lookups is the reasonable thing to do. In accordance with RFC3484, getaddrinfo will put IPv4 addresses ahead of IPv6 for any remote host, so it's wasteful to perform DNS lookups for IPv6. I'm not even clear how SLAAC addresses are available to DNS.


On the networks I've been trying this on, DNS is provided by DHCPv4, so the DNS servers are IPv4 addresses (no RFC 5006 support on the upstream routers).  I'm not sure how to interpret your comment about SLAAC addresses being available to DNS.  SLAAC provides a global address in addition to a default route.

I don't think there is, but if there were a delay (not more than a second or two) in the IPv6 RA packet being received as a result of an RS packet from ChromeOS, do you think this is what might be happening?  I'm guessing that when ChromeOS does its testing, it does it too early, before the global address is bound to the interface.

Also, SSH works and has always worked just fine to remote [Internet, a few hops away, etc.] hosts.

- Mark

Comment 21 by szym@chromium.org, Jun 20 2012

SLAAC uses link-local, but the retrieved configuration is clearly a global-scoped IPv6 if ssh works over IPv6 beyond the LAN. I got confused for a moment. 

It's possible that timing is the issue here, although Chrome is supposed to detect when the global address is added and re-test. Chrome is using RTNETLINK to detect the change, so it should work. 

SLAAC only uses link-local for ND.  The RA (part of ND) message provides a prefix (almost always global) that is used for autoconfiguration.  ChromeOS then constructs an address via EUI-64 and also attaches RFC 4941 addresses.  For example:

crosh> shell
chronos@localhost / $ ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 48:5d:60:77:33:19  
          inet addr:10.3.6.111  Bcast:10.3.6.255  Mask:255.255.255.0
          inet6 addr: 2001:48c8:1:106:4a5d:60ff:fe77:3319/64 Scope:Global
          inet6 addr: fe80::4a5d:60ff:fe77:3319/64 Scope:Link
          inet6 addr: 2001:48c8:1:106:d0fc:92e0:9a3:b995/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:349 errors:0 dropped:1 overruns:0 frame:0
          TX packets:316 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:213632 (208.6 KiB)  TX bytes:57929 (56.5 KiB)

This is a very common setup at this point in the evolution of IPv6.

- Mark

Comment 23 by rpwoo...@mybox.org, Sep 28 2012

What's the latest here?  I can also confirm this behavior.

> In accordance with RFC3484, getaddrinfo will put IPv4 addresses ahead of IPv6 for any remote host, so it's wasteful to perform DNS lookups for IPv6. 

It may seem wasteful at first blush, but not looking up AAAA records breaks the ability to access IPv6-only websites.  Such sites are rare for now, but I do have some I use for internal purposes (plus I need to ssh to backend machines that are only available over IPv6), and having to fiddle with this setting each time I boot doesn't seem right.


Comment 24 by szym@chromium.org, Sep 28 2012

Cc: pstew@chromium.org
Owner: szym@chromium.org
Re #23. It's only wasteful if there's no global IPv6 connectivity, since there will be no way to reach the addresses in those AAAA records.

However, the problem here is that the host appears to have a global IPv6 address, and therefore Chrome should not default to IPv4-only. It's a bug.

HostResolverImpl will probe for IPv6 whenever it receives OnIPAddressChanged, but Mark's histograms suggest that there's no probe. I see this is CrOS specific, which suggests either 
(A) that shill does not send the notification when the IPv6 address is acquired via SLAAC or 
(B) that NetworkChangeNotifierChromeos suppresses the notification because this is a _new_ address, but rather on top of the old IPv4 address.

Just to confirm this is CrOS specific, could you experiment with Chrome on a different platform (Win, Mac, Linux)?

Comment 25 by szym@chromium.org, Sep 28 2012

Clarification: Mark's observations suggest that the probe might be too early (i.e., when the first IPv4 is configured, but before IPv6 is added).

Comment 26 by jar@chromium.org, Sep 28 2012

To add a third hypothesis to #24:

(C) Perhaps the observer that has the potential for receiving the notification was added after the IPv6 address was acquired.


Please check to see that we do the probe after we have added the observer.  If not, we could have the sequence:

1- startup
2- probe (no global ipv6 address found)
3- IPv6 address added
4- Observer for changes in interfaces and address inserted.

Comment 27 by rpwoo...@mybox.org, Sep 28 2012

I can confirm that I've never had this problem with Chrome on Ubuntu Linux, even on the same network that depends on SLAAC.  I think you're onto something here.


What you are describing is "hampered eyeballs".  It looks like the Chrome (or more likely MacOS?)  "happy eyeballs" algo is being too "happy".  Great for speeding up browsing, but not so good for people who want to absolutely prefer IPv6, esp for testing.  It also hoses IPv6 deployment measurements.

https://labs.ripe.net/Members/emileaben/hampered-eyeballs

On the same MacOS 10.7.5 machine, Firefox correctly uses IPv6 to get to dual-stack servers, Chrome fails and uses IPv4 80+% of the time.  I'm guessing that the cases where I'm getting fallback to Ipv4 in Chrome is because the IPv6 connection is just a few ms too slow compared to the IPv4 path and that Firefox isn't being as aggressive

I don't know why you picked this bug thread to start talking about hampering eyeballs.
* This is a bug thread about ChromeOS DNS behavior, not OS X.
* As noted in the link you provided, Chrome is generally more resistent to hampering eyeballs:
"""
The Chrome implementation of "Happy Eyeballs" on the other hand seems to adequately avoid a degraded user experience ("Unhappy Eyeballs") when visiting broken dual-stacked hosts, and at the same time doesn't cause "Hampering Eyeballs" in significant numbers.
"""
Project Member

Comment 30 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Internals-Network -Internals-Network-DNS Cr-Internals Cr-Internals-Network Cr-Internals-Network-DNS

Comment 31 by lorenzo@google.com, Mar 26 2013

I'm confused as to why we run this probe at all. All it does is check that the machine has a global IPv6 address and can create IPv6 sockets, right?

If so, then what benefit does the probe provide that we can't get by passing simply callign getaddrinfo with the AI_ADDRCONFIG flag? That essentially does the same thing.

Comment 32 by szym@chromium.org, Mar 26 2013

Cc: quiche@chromium.org
Status: Started
This probe is the equivalent of AI_ADDRCONFIG for Chrome's built-in asynchronous DNS stub resolver (which now is the default on CrOS).

AI_ADDRCONFIG is implemented by enumerating all the addresses at the moment of the call. The probe does the same thing, but is intended to run only when there's an expectation of change since the last time.

I think we should be using the AddressTrackerLinux which registers for notifications from kernel over netlink. This is necessary anyway for address sort (RFC3484/6724).

Comment 33 by lorenzo@google.com, Mar 26 2013

Szymon, are you saying that we run this probe because the CrOS resolver doesn't support AI_ADDRCONFIG at all? If so, wouldn't it be better to support AI_ADDRCONFIG in the CrOS resolver instead of relying on the probe?

As this bug shows, the probe can get out of sync sometimes (I think I've seen that happen on Linux as well, not just CrOS). Also, it's nonstandard and can only be used by Chrome and not by other apps.

Comment 34 by szym@chromium.org, Mar 26 2013

The built-in DNS resolver is intended to run on all platforms (where possible), not just CrOS.

For all intents and purposes, the probe IS AI_ADDRCONFIG for the built-in resolver, which uses the probe results the same way getaddrinfo uses AI_ADDRCONFIG, i.e. to determine if both A and AAAA records are needed from DNS.

The reason why the probe gets out of sync is because we didn't foresee that there could be address changes that are not indicated by shill (CrOS' network manager). AddressTrackerLinux would address this. The alternative would be a glibc-like implementation: on every resolution, enumerate the addresses to determine A/AAAA. This is feasible, but it will take more work than just making the probe accurate.

Regarding last comment: The processes on CrOS either have access to Chrome's HostResolver and therefore depend on the probe (asking for AF_UNSPEC family means that resolver decides) or use getaddrinfo from glibc (with its AI_ADDRCONFIG).

Cc: gauravsh@chromium.org
@szym: Can you say more about the address change events you're missing on CrOS? Maybe that's something we can fix in shill or the Chrome code that talks to shill...

[+gauravsh for shill/Chrome change notifications]

Comment 36 by szym@chromium.org, Mar 27 2013

Re #35, see #24

I am only guessing from the symptoms (IPv6 detected after manual probe trigger) that either shill does not notify or NetworkChangeNotifierChromeos ignores such notification when the IPv6 address is added to an interface with a prior IPv4 address. In consequence, the IPAddressObservers are not notified and the TestIPv6Support probe is not re-run on that event.

[DATA INTERLUDE]
Our histogram data suggests that <1% of CrOS users have IPv6 support on first test and that grows to 5.5% on retest (network change). We would expect the second number in particular to be a lot higher. In contrast, Mac users report IPv6 support in >15% tests.
[END DATA INTERLUDE]

That said, AddressTrackerLinux (which simply hooks up to kernel via netlink) would detect such changes, and we would need it anyway to be fully RFC3484/6724-compliant. Furthermore, from my conversation with lorenzo@, the address sorting rules that need info straight from the kernel are rather exotic, so we might not need really them.

Finally, we might be able to get rid of the TestIPv6Support probe **entirely** by replacing it with a lightweight on-demand using connect(UDP)+getsockname:  Issue 223876 .

Thanks, @szym. Sounds like you've got a plan forward, so I've forked off the question of whether or not shill's sending the right signals into  bug 224312 .

Comment 38 by lorenzo@google.com, Mar 27 2013

From reading  bug 224312  it seems that on CrOS, IPv6 address changes are not notified at all. That means that IPv4 addresses are configured before IPv6 addresses, then the probe is never run (and IPv6 never gets used) until the next network change event.

That would definitely explain the fact that we see Chrome on CrOS prefer IPv6 subtantially less often than on Windows. By itself, it wouldn't explain the fact that we see Chrome on Windows prefer IPv6 ~5% less often than MSIE on Windows, unless the probe on Windows is not being triggered either.

I'm definitely a fan of either switching to the addresstracker or getting rid of the probe entirely (assuming AI_ADDRCONFIG is either unnecessary or does what we want on all platforms).

Comment 39 by szym@chromium.org, Apr 29 2013

Blockedon: chromium:223876
Hi all,

I'm also seeing this behavior on Windows 7 ENT when DirectAccess is enabled. Since the DirectAccess tunnel (IPV6 only) gets created a few seconds after the PC establishes internet connectivity, IPV6 is always disabled in chrome.

It would be great if Chrome can do a the probe every so many seconds if it doesn't detect an IPv6 address initially.

Comment 41 by szym@chromium.org, Jun 25 2013

Starting with Chrome 28 (r195406 to be exact), the host resolver checks for IPv6 support on every request rather than on network changes. Please try on Chrome Beta (28) or wait until 28 becomes stable.

If you are already on Beta and you are still experiencing similar issue, please follow http://dev.chromium.org/for-testers/providing-network-details

Comment 42 by szym@chromium.org, Jul 15 2013

Status: Fixed
I don't believe this is fixed. I have Chrome Version 28.0.1500.72 m and I'm still seeing the issue when using Direct Access on Windows 7 where Chrome doesn't enable IPv6. I've even closed Chrome and re-opened it hoping that it would do another probe but it still comes back with IPv6 disabled.

It says: Default address family: IPV4 (IPv6 disabled)  

When I go to chrome://histograms/ I see this:

Histogram: Net.IPv6Status recorded 1 samples, average = 3.0 (flags = 0x1)
0  ... 
3  ------------------------------------------------------------------------O (1 = 100.0%) {0.0%}
4  ... 

Here is the part of an ipconfig /all showing the Direct Access tunnel with the ipv6:
Tunnel adapter Local Area Connection* 11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Teredo Tunneling Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:0:454a:ffb4:10b7:1ccc:e7ff:bd41(Preferred)
   Link-local IPv6 Address . . . . . : fe80::10b7:1ccc:e7ff:bd41%11(Preferred)
   Default Gateway . . . . . . . . . : ::
   NetBIOS over Tcpip. . . . . . . . : Disabled

Comment 44 by szym@chromium.org, Jul 23 2013

Status: Assigned
It turns out that the solution in r195406 is incompatible with Direct Access.

The current workaround is to force IPv6 via chrome://net-internals/#dns (temporarily) or --enable-ipv6 command-line flag.

Thanks for the command line tip. Are there any plans on fixing the ipv6 check so that it works with direct access?

Comment 46 Deleted

Comment 47 by Deleted ...@, Aug 20 2013

Any updates on this? I have the same issue on WIN7 ENT with DirectAccess. IPV6 disabled in Chrome and have to manually enable ipv6 in Chrome each time it starts using chrome://net-internals/#dns or doing command line flag mentioned in #44

Comment 48 by szym@chromium.org, Aug 20 2013

Status: Fixed
This issue is caused by the interaction between CrOS network manager and Chrome. I'm re-closing it as fixed.

 Issue 259792  tracks the problem with DirectAccess. Chrome 29 should work as expected with DirectAccess, unless the host has no global IPv6 address.

Comment 49 by szym@chromium.org, Aug 20 2013

Summary: ChromeOS: IPv4-only DNS on IPv6 network (was: IPv4-only DNS on IPv6 network)
Labels: VerifyIn-31
Cc: krisr@chromium.org
Status: Verified
Verified with 4731.3.0,R31.

Sign in to add a comment