Fixed
Status Update
Comments
to...@gmail.com <to...@gmail.com> #2
I note that running IPv6-only over GPRS/3G works fine, so this is just a "network manager" issue. It would be nice to get it working over WiFi as well. My home network is currently IPv6 only (SLAAC + DHCPCv6 (for DNS) with DNS64/NAT64). Works fine in Windows 7. Android and ChromeOS have problems.
Feel free to usehttp://dual.tlund.se/ for testing connectivity :)
Feel free to use
ni...@gmail.com <ni...@gmail.com> #3
From RFC 6540 (http://tools.ietf.org/html/rfc6540 ):
o New and updated IP networking implementations should support IPv4
and IPv6 coexistence (dual-stack), but must not require IPv4 for
proper and complete function.
Sadly, devices running iOS are able to function on IPv6 only WiFi networks.
o New and updated IP networking implementations should support IPv4
and IPv6 coexistence (dual-stack), but must not require IPv4 for
proper and complete function.
Sadly, devices running iOS are able to function on IPv6 only WiFi networks.
na...@google.com <na...@google.com> #4
Is there a reason not to do this?
I wonder if this bug has not been looked at due to prioritisation or perceived risks?
Do we know of any cases where people have been saved from broken connections due to this behavior?
Thanks!
I wonder if this bug has not been looked at due to prioritisation or perceived risks?
Do we know of any cases where people have been saved from broken connections due to this behavior?
Thanks!
ni...@gmail.com <ni...@gmail.com> #5
An IPv6-only WiFi network is admittedly rare at present. The idea is to get the code into the codebase so that the bugs can be worked out in test environments. Someday soon in APNIC or RIPE regions such a connection may be encountered.
al...@gmail.com <al...@gmail.com> #6
Why not just disable the "refresh on lack of IPv4" part and start testing, or at least have an option for that? It shouldn't be that difficult.
to...@fud.no <to...@fud.no> #7
"Sadly, devices running iOS are able to function on IPv6 only WiFi networks."
Why is this sad? I think it is great that other implementations support IPv6. Also Mac OS X, Windows, Linux (at least desktop distros like Fedora and Ubuntu) all support IPv6-only networks. In my opinion, the only sad thing here is that Android does not - to the best of my knownledge, it is the only major end-user operating system to not have full support for IPv6.
"Is there a reason not to do this? I wonder if this bug has not been looked at due to prioritisation or perceived risks?"
The only reason that I see is that they haven't bothered to code it up. As far as I can tell, there is *NO* code in Android itself to support IPv6 on WiFi whatsoever. The only thing that is supported, is what they got gratis by using the Linux kernel - in other words IPv6 ND and SLAAC. It actually works worse than in vanilla unpatched Linux - see issue 36949115 . (I suspect some power management patch is to blame here.)
"An IPv6-only WiFi network is admittedly rare at present"
A self-fulfilling prophecy, if this is really being used as an excuse for not bothering. Nobody in their right mind would deploy an IPv6-only WiFi network when the largest mobile OS cannot connect to it. Furthermore, since most Android devices are rarely kept up-to-date, every single Android device being sold today without IPv6 support is pushing the viability for such IPv6-only WiFi networks even further into the future. As noted above, the other major operating systems do support IPv6-only just fine, so Android is exclusively to blame for hampering the deployment of IPv6 here.
It is a real shame. Google is a world leader in and ardent supporter of IPv6 deployment in many other ways, for example by being one of the initiators to World IPv6 Launch and having deployed IPv6 on all their web content and most of their enterprise networks. When it comes to Android, on the other hand, they are the worst in class - they don't seem to care about IPv6 at all. I their left hand doesn't know what the right hand is doing.
Tore
Why is this sad? I think it is great that other implementations support IPv6. Also Mac OS X, Windows, Linux (at least desktop distros like Fedora and Ubuntu) all support IPv6-only networks. In my opinion, the only sad thing here is that Android does not - to the best of my knownledge, it is the only major end-user operating system to not have full support for IPv6.
"Is there a reason not to do this? I wonder if this bug has not been looked at due to prioritisation or perceived risks?"
The only reason that I see is that they haven't bothered to code it up. As far as I can tell, there is *NO* code in Android itself to support IPv6 on WiFi whatsoever. The only thing that is supported, is what they got gratis by using the Linux kernel - in other words IPv6 ND and SLAAC. It actually works worse than in vanilla unpatched Linux - see
"An IPv6-only WiFi network is admittedly rare at present"
A self-fulfilling prophecy, if this is really being used as an excuse for not bothering. Nobody in their right mind would deploy an IPv6-only WiFi network when the largest mobile OS cannot connect to it. Furthermore, since most Android devices are rarely kept up-to-date, every single Android device being sold today without IPv6 support is pushing the viability for such IPv6-only WiFi networks even further into the future. As noted above, the other major operating systems do support IPv6-only just fine, so Android is exclusively to blame for hampering the deployment of IPv6 here.
It is a real shame. Google is a world leader in and ardent supporter of IPv6 deployment in many other ways, for example by being one of the initiators to World IPv6 Launch and having deployed IPv6 on all their web content and most of their enterprise networks. When it comes to Android, on the other hand, they are the worst in class - they don't seem to care about IPv6 at all. I their left hand doesn't know what the right hand is doing.
Tore
ni...@gmail.com <ni...@gmail.com> #8
6 month nudge. Is this thing even being ready by Google/Android engineering?
pc...@gmail.com <pc...@gmail.com> #9
I would like to see IPv6-only functionality in Android as well. I'm a little disappointed to see how far behind Android compared to iOS.
al...@gmail.com <al...@gmail.com> #10
From reading the [lack of] responses, it appears that there are other priorities or interests in the dev team, which is completely understandable, being Android the monster it already is.
We must speak with code then. Can this be fixed by us? I'm no dev, but I can give it a shot. It should be a matter of preventing Android from looping through IPv4. Does anyone around know the Android code base?
We must speak with code then. Can this be fixed by us? I'm no dev, but I can give it a shot. It should be a matter of preventing Android from looping through IPv4. Does anyone around know the Android code base?
dm...@gmail.com <dm...@gmail.com> #11
I agree. If we can come up with a patch for AOSP that applies cleanly, then chances should be much better.
I'd be happy to test any patches against AOSP on my Nexus 4 as I have the environment set up anyway. I won't be able to work on a patch myself though due to other projects having much higher priority at the moment.
I'd be happy to test any patches against AOSP on my Nexus 4 as I have the environment set up anyway. I won't be able to work on a patch myself though due to other projects having much higher priority at the moment.
jj...@jjmb.com <jj...@jjmb.com> #12
I just commented on some other similar issues and also would be willing to work on a patch. It is necessary and sounds like an interesting project.
dm...@gmail.com <dm...@gmail.com> #13
Someone just found a workaround on #ipv6 of freenode:
06:43:01< p1mrx> so I just figured out how to do IPv6-only WiFi on Android. set the IP to "Static", type in 0.0.0.0 for the IP and gateway, and fill in an IPv6 DNS resolver. You might also have to check "avoid poor connections".
Haven't tried it yet, but sounds promising
06:43:01< p1mrx> so I just figured out how to do IPv6-only WiFi on Android. set the IP to "Static", type in 0.0.0.0 for the IP and gateway, and fill in an IPv6 DNS resolver. You might also have to check "avoid poor connections".
Haven't tried it yet, but sounds promising
pm...@google.com <pm...@google.com> #14
Here's some more detailed steps. I'm not on the Android team, so don't blame me if your packets catch fire:
- WiFi > Advanced > Uncheck "Avoid poor connections" (not sure if this is always necessary)
- Long-press on your SSID
- Select "Modify network"
- Set "IP settings" to "Static"
- IP address = 0.0.0.0
- Gateway = 0.0.0.0
- DNS 1 = 2001:4860:4860::8888
- Save
It works for me on Jelly Bean, but not on Gingerbread.
- WiFi > Advanced > Uncheck "Avoid poor connections" (not sure if this is always necessary)
- Long-press on your SSID
- Select "Modify network"
- Set "IP settings" to "Static"
- IP address = 0.0.0.0
- Gateway = 0.0.0.0
- DNS 1 = 2001:4860:4860::8888
- Save
It works for me on Jelly Bean, but not on Gingerbread.
we...@gmail.com <we...@gmail.com> #15
You can also try to configure a 169.254.x.x (RFC3927 Link Local) address instead of 0.0.0.0. This is what Windows does automatically when DHCPv4 times out, and it seems to help IPv4 connection attempts time out much faster (at least on WindowS). This is a useful workaround for early testing, and I appreciate you posting it, but the ultimate goal is that an Android device comes up happily on an IPv6-only connection without any hackery or changes from the defaults in the same way that any current Desktop OS does.
Also, YMMV as to whether you can actually reach a UI screen to configure IPv6 DNS servers manually. AFAICT, at least Asus's flavor of Jellybean doesn't have any IPv6-specific config UI. I didn't test to see if it would reject an IPv6 DNS server populated in the IPv4 field, I'll try that tonight.
Also, YMMV as to whether you can actually reach a UI screen to configure IPv6 DNS servers manually. AFAICT, at least Asus's flavor of Jellybean doesn't have any IPv6-specific config UI. I didn't test to see if it would reject an IPv6 DNS server populated in the IPv4 field, I'll try that tonight.
ni...@gmail.com <ni...@gmail.com> #16
While these workaround are all potentially useful, the purpose of this bug report is to encourage upstream to enable this functionality by default.
jj...@jjmb.com <jj...@jjmb.com> #17
[Comment deleted]
jj...@jjmb.com <jj...@jjmb.com> #18
Thanks for the information, manually configuring IPv4 to 0.0.0.0 and other attributes may be useful for test however for production deployment will need one of the other options we have been discussing on this thread.
ni...@gmail.com <ni...@gmail.com> #19
Just upgraded to Android 4.3. Attempting to connect to my IPv6 only WiFi test network results in the same: Sitting at "Obtaining IP address..." for a minute or so then dropping the interface.
ro...@gmail.com <ro...@gmail.com> #20
There is a IPv6 only SSID running at RIPE67, all other OS'es seems to handle that well except for Android, which is quite sad.
All of my devices fail, that is Android 4.0.4 upto Android 4.3 (Nexus 7).
https://www.ripe.net/ripe/mail/archives/ipv6-wg/2013-October/002190.html
All of my devices fail, that is Android 4.0.4 upto Android 4.3 (Nexus 7).
ei...@etherkiller.de <ei...@etherkiller.de> #21
Same goes for FOSDEM '14. NAT64 SSID which works well except for Android users.
ha...@gmail.com <ha...@gmail.com> #22
Same here for FOSDEM 2014 for me and many other users. Connecting to the provided dual-stack network went fine, yet the IPv6-only network didn't. It went up till "Obtaining IP address.." and then it dropped it again.
ce...@gmail.com <ce...@gmail.com> #23
idem, experienced problem during #fosdem 2014
br...@gmail.com <br...@gmail.com> #24
Let's hope Nexus users will be able to use the IPv6 network at FOSDEM next year ;) Had to fall back to the dual stack network (or eduroam).
la...@gmail.com <la...@gmail.com> #25
No IPv6 for my Nexus 7 at Fosdem this year :-(
li...@linuxonrails.com <li...@linuxonrails.com> #26
No IPv6 in my android 4.1.2 at Fosdem 2014 :(
ma...@gmail.com <ma...@gmail.com> #27
Android did not work at Fosdem 2014. :(
wi...@tilanus.com <wi...@tilanus.com> #28
Had this problem with my Android 4.1.1 phone at Fosdam 2014.
sa...@gmail.com <sa...@gmail.com> #29
Android device failed at FOSDEM2014. Fix. Kthx.
k....@gmail.com <k....@gmail.com> #30
FOSDEM2014 with android devices was a disaster. Fix it!
ke...@gmail.com <ke...@gmail.com> #31
My Nexus 7 was unable to acquire an IPv6 address @ FOSDEM2014. Common guys, we are 2014, it is not that IPv6 is something new ...
ma...@gmail.com <ma...@gmail.com> #32
FOSDEM STAFF member comment:
To vote, just click on star in upper left corner ... after authentication.
DO NOT add pointless comments. It's just spam for all the people that starred (voted) on the issue.
To vote, just click on star in upper left corner ... after authentication.
DO NOT add pointless comments. It's just spam for all the people that starred (voted) on the issue.
st...@gmail.com <st...@gmail.com> #33
No IPV6, neither on my Nexus4, nor on my Nexus7 during FOSDEM 2014.
ni...@gmail.com <ni...@gmail.com> #34
Google has made it quite clear that IPv6 support on WiFi is not a priority for their developers. https://plus.google.com/+KevinOtte/posts/JUHVxyW1AB3
We either need to speak with code or our wallets.
We either need to speak with code or our wallets.
cb...@gmail.com <cb...@gmail.com> #35
Agreed. Google needs to fix. Even windows 7 works on ipv6-only with nat64
mi...@gmail.com <mi...@gmail.com> #36
FOSDEM-v6 didn't connect. :(
ai...@gmail.com <ai...@gmail.com> #37
Please just star the issue if you have the same problem or comment something usefull in stead of basicly saying "me too".
Starring it has the same, if not better, effect.
Plus, it keeps our mailboxes clean.
Starring it has the same, if not better, effect.
Plus, it keeps our mailboxes clean.
[Deleted User] <[Deleted User]> #38
Not supporting RDNSS Option is also a shame. This should get fixed as soon as possible. There is no nees for simple networks to use RA and DHCPv6 at the same time for such a trivial task as supplying one or more recursive DNS server addresses.
Next Smartphone I buy will be running in an IPv6 only network anyway. If it is only apple that provide the required features then i will have to migrate. :/
Next Smartphone I buy will be running in an IPv6 only network anyway. If it is only apple that provide the required features then i will have to migrate. :/
ts...@t-online.de <ts...@t-online.de> #39
Has anybody details about the coming update 4.4.3?
There are announcements about IPv6-fixex, but only very general, not in detail.
There are announcements about IPv6-fixex, but only very general, not in detail.
gd...@gmail.com <gd...@gmail.com> #40
And yet another RIPE meeting, without working IPv6-only connectivity for Android users...
[Deleted User] <[Deleted User]> #41
Ridiculous.
on...@gmail.com <on...@gmail.com> #42
It it indeed ridiculous that devs are not able to fix such clear and simple bug in two years.
ai...@gmail.com <ai...@gmail.com> #43
Is it fixed in 4.4.3?
Has anyone been able to test this?
In the expected bugfixes:
"MMS, Email/Exchange, Calendar, People/Dialer/Contacts, DSP, _IPv6_, VPN fixes "
No official release notes yet though.
Source:http://www.androidpolice.com/2014/03/28/first-android-4-4-3-details-come-to-light-here-is-what-you-should-expect-to-see-fixed/
Has anyone been able to test this?
In the expected bugfixes:
"MMS, Email/Exchange, Calendar, People/Dialer/Contacts, DSP, _IPv6_, VPN fixes "
No official release notes yet though.
Source:
rc...@gmail.com <rc...@gmail.com> #44
[Comment deleted]
rc...@gmail.com <rc...@gmail.com> #45
Still broken with 4.4.3 on my Nexus 5. It will not bring up the wlan0 interface without a DHCPv4 or manually configured IPv4 address.
ja...@gmail.com <ja...@gmail.com> #46
I already have IPv6-Only at home and I realized about this issue on my "Samsung S5 Android 4.4.2"; honestly I couldn't believe that the reason was the dependency on IPv4 instead of IPv6.
I think it's time to fix the issue, we're on 2014 and the IPv4 addresses are almost gone, therefore IPv6 is a must.
I think it's time to fix the issue, we're on 2014 and the IPv4 addresses are almost gone, therefore IPv6 is a must.
dr...@gmail.com <dr...@gmail.com> #47
If I understand correctly, there is neither support for RFC6106 https://code.google.com/p/android/issues/detail?id=32629 nor DHCPv6 https://code.google.com/p/android/issues/detail?id=32621 yet, so android cannot fetch DNS server information by IPv6 means. Consequently, it won’t be able to do much without IPv4 DHCP providing a DNS address.
ts...@t-online.de <ts...@t-online.de> #48
You are right, there dependencies to other bugs. But they should be fixed too.
All other OS (except the obsolete winXP) support IPv6-only-connections with DNS configured by dhcpv6 and/or RA options for DNS conf.
This is a big show stopper. Some wifi/wlan-Provider, i know, would switch to IPv6 only ( with little bit NAT64 in the background). But they can't, if 50% of the popular smartphones/tablets don't connect.
On the other hand, at wan-interface android supports IPv6-only, or are my sources/information about t-mobile US wrong?
All other OS (except the obsolete winXP) support IPv6-only-connections with DNS configured by dhcpv6 and/or RA options for DNS conf.
This is a big show stopper. Some wifi/wlan-Provider, i know, would switch to IPv6 only ( with little bit NAT64 in the background). But they can't, if 50% of the popular smartphones/tablets don't connect.
On the other hand, at wan-interface android supports IPv6-only, or are my sources/information about t-mobile US wrong?
jc...@gmail.com <jc...@gmail.com> #49
Much of the code to add support for IPv6-only networks has already been written and is here: https://android-review.googlesource.com/#/c/78857/
That patch updates the built in dhcpcd software to support DHCPv6 and RDNSS. Unfortunately, it needs a bit of work. Some parts of the implementation aren't great and it's already using outdated software.
That patch updates the built in dhcpcd software to support DHCPv6 and RDNSS. Unfortunately, it needs a bit of work. Some parts of the implementation aren't great and it's already using outdated software.
si...@gmail.com <si...@gmail.com> #50
re: #47
t-mobile samsung blaze in the house on rooted GB (to preserve wifi calling) works perfectly with my dual-stack wlan, only gets a 100./28 and it's ipv6 link-local via 4G in Florida, 172.56.x.x wan side. ipv6 tests failed.
t-mobile samsung blaze in the house on rooted GB (to preserve wifi calling) works perfectly with my dual-stack wlan, only gets a 100./28 and it's ipv6 link-local via 4G in Florida, 172.56.x.x wan side. ipv6 tests failed.
mi...@gmail.com <mi...@gmail.com> #51
Hello,
I have a Iocean G7 (android 4.2.2, MT6592 processor) on a Freebox router with IPv6 (I'm living in France).
Wifi on my G7 is very slow, website loading freezes.
Today, I find it was because of IPv6. When I switch it off, wifi download works fine on my G7.
But I need IPv6 on my personnal computer.
Can someone help me ?
Thanks a lot.
(Sorry for my bad english)
I have a Iocean G7 (android 4.2.2, MT6592 processor) on a Freebox router with IPv6 (I'm living in France).
Wifi on my G7 is very slow, website loading freezes.
Today, I find it was because of IPv6. When I switch it off, wifi download works fine on my G7.
But I need IPv6 on my personnal computer.
Can someone help me ?
Thanks a lot.
(Sorry for my bad english)
ts...@t-online.de <ts...@t-online.de> #52
at #50
You describe a totally different problem.
Because you are probably speaking about IPv6 in a dualstack environment. Maybe you write a new issue, contact your device vendor, your isp or your router vendor(firewallsettings).
This bug is about: IPv6 connection without assistance of IPv4.
You describe a totally different problem.
Because you are probably speaking about IPv6 in a dualstack environment. Maybe you write a new issue, contact your device vendor, your isp or your router vendor(firewallsettings).
This bug is about: IPv6 connection without assistance of IPv4.
ts...@t-online.de <ts...@t-online.de> #53
Surprise - Lollipop :-)
and the problem still persists :-(
and the problem still persists :-(
pm...@google.com <pm...@google.com> #54
tschae...: Does your IPv6-only network advertise RDNSS?
ts...@t-online.de <ts...@t-online.de> #55
The first test I made, was with an commercial product with dhcpv6.(Vodafone W5101 with disabled IPv4-dhcp).
I will do further tests - within a synthesized environment(with RCF6106,also better for traces)
I will do further tests - within a synthesized environment(with RCF6106,also better for traces)
ts...@t-online.de <ts...@t-online.de> #56
Yeah, 50% of the problem is solved.
With RFC6106(also known as 5006) without other/managed flag it works.
For the people who want to confirm my test. It is not necessary to create your own testlab.
I did it with a normal fritzbox(dualstack), just by disabling dhcpv4, dhcpv6, enabling RFC5006 and setting public NAT64/DNS-Resolvers.
Then I made I test with a notebook for reference and checking, if the fritzbox does not lie.
After that - finally - I did the test with the nexus.
It connects, uses the right DNS-resolver. But it does not start clatd.
You can see it here: 8.8.8.8 is not reachable.
https://www.netztest.at/de/Opentest?O56757744-f2cc-4a71-a7ee-611ebe377a18
I vote to keep the bug open.
Support of RDNSS is nice, but the world is more complex.
With RFC6106(also known as 5006) without other/managed flag it works.
For the people who want to confirm my test. It is not necessary to create your own testlab.
I did it with a normal fritzbox(dualstack), just by disabling dhcpv4, dhcpv6, enabling RFC5006 and setting public NAT64/DNS-Resolvers.
Then I made I test with a notebook for reference and checking, if the fritzbox does not lie.
After that - finally - I did the test with the nexus.
It connects, uses the right DNS-resolver. But it does not start clatd.
You can see it here: 8.8.8.8 is not reachable.
I vote to keep the bug open.
Support of RDNSS is nice, but the world is more complex.
to...@fud.no <to...@fud.no> #58
tschae...@t-online.de, do you really need to disable DHCPv6 and the O-flag for it to work?
If so, that is quite problematic, because certain operating systems (e.g., Microsoft Windows) does not support RFC6106/RFC5006 and thus requires the O-flag to be set and DHCPv6 to be available (at least in stateless information-only mode). If Android requires the exact opposite as you suggest, the logical consequence is that it is impossible to support both Android and Windows clients on the same IPv6-only wireless network.
Tore
If so, that is quite problematic, because certain operating systems (e.g., Microsoft Windows) does not support RFC6106/RFC5006 and thus requires the O-flag to be set and DHCPv6 to be available (at least in stateless information-only mode). If Android requires the exact opposite as you suggest, the logical consequence is that it is impossible to support both Android and Windows clients on the same IPv6-only wireless network.
Tore
rc...@gmail.com <rc...@gmail.com> #59
[Comment deleted]
ts...@t-online.de <ts...@t-online.de> #60
Ok I will do further tests.
The question in #53 was about support of RDNSS
Of course, there are more than one constellation.
The question in #53 was about support of RDNSS
Of course, there are more than one constellation.
ts...@t-online.de <ts...@t-online.de> #62
#57, #58, #59, #60
I think
https://code.google.com/p/android/issues/detail?id=32629
can be closed.
I made the test requested in #c57.
It is not neccessary to disable "other" and "dhcpv6".
It did work with RFC6106 on, other-flag=1, mananged=0 and dhcpv6 with DNS-info.
Because I have no rooted device. I used different test-sites/apps and the he-tools (app) to see the local DNS-configuration.
Android is not very friendly for diagnostics.
I run windows(7) in parallel, to see if it still works.
In windows it is not enough to disable dhcpv4 on server-site. Windows still tries the old configuration, also after reboot. I had to disable IPv4 in windows too. ( I could not switch off IPv4 at the router completely)
I think
can be closed.
I made the test requested in #c57.
It is not neccessary to disable "other" and "dhcpv6".
It did work with RFC6106 on, other-flag=1, mananged=0 and dhcpv6 with DNS-info.
Because I have no rooted device. I used different test-sites/apps and the he-tools (app) to see the local DNS-configuration.
Android is not very friendly for diagnostics.
I run windows(7) in parallel, to see if it still works.
In windows it is not enough to disable dhcpv4 on server-site. Windows still tries the old configuration, also after reboot. I had to disable IPv4 in windows too. ( I could not switch off IPv4 at the router completely)
lo...@google.com <lo...@google.com>
va...@gmail.com <va...@gmail.com> #63
Over 3 years past, nothing has been changed.
I has also noticed this problem since someday I tried to establish internet connection within IPV6-only network.
I almost tried to reset my phone until I learned what's happened by myself.
What a unbelievable bug, exists over 3 years!
I has also noticed this problem since someday I tried to establish internet connection within IPV6-only network.
I almost tried to reset my phone until I learned what's happened by myself.
What a unbelievable bug, exists over 3 years!
ne...@gmail.com <ne...@gmail.com> #64
The hacker conference FOSDEM, to help flush network issues with IPv6 only networks, hAve run an IPv6 network for the past 4 years, and as the default for the past 2 years. When I connect to the FOSDEM network, the behavior is that the network connects and appears to work, but there's no proper connections.
May I suggest having some Android devs spend a weekend in Brussels next year, perhaps as part of an Android DevRoom, and take advantage of the opportunity to flush out issues with IPv6?
Thanks,
Dave.
May I suggest having some Android devs spend a weekend in Brussels next year, perhaps as part of an Android DevRoom, and take advantage of the opportunity to flush out issues with IPv6?
Thanks,
Dave.
ri...@gmail.com <ri...@gmail.com> #65
I am writing this from Android 6.0.1 on the NAT64 network.
What version of Android are you using?
Richard
Sent by mobile; excuse my brevity.
What version of Android are you using?
Richard
Sent by mobile; excuse my brevity.
ts...@t-online.de <ts...@t-online.de> #66
Ipv6-only doesn't equal ipv6-only.
Mobile networks (e.g.LTE) work fine.
WiFi with rfc6106 works fine.
WiFi with dhcpv6 doesn't work.
This is a very old undiscussion at
https://code.google.com/p/android/issues/detail?id=32621
Google doesn't support dhcpv6 and most Cisco routers don't support rfc6106.
So android is not usable in company networks.
Mobile networks (e.g.LTE) work fine.
WiFi with rfc6106 works fine.
WiFi with dhcpv6 doesn't work.
This is a very old undiscussion at
Google doesn't support dhcpv6 and most Cisco routers don't support rfc6106.
So android is not usable in company networks.
er...@gmail.com <er...@gmail.com> #67
One can imagine Corporate office routers (i.e. Cisco) likely won't implement RFC6106 or strongly recommend disabling it, because SLAAC has security issues for IT in big companies. DHCPv6 is all that allows for white-knuckle grip on domain host control ... oh wait that's why they call it that (thick sarcasm)
First and foremost against pure SLAAC, nobody wants their MAC on the public internet (::HOSTID = MAC with special insert). When your market research team goes on a road trip, then there activity at home can be correlated with trip data, and that's just giving away product futures to corporate espionage.
Second even alternate permanent SLAAC assignment like making up a random one during OS install, creates a world wide track-able machine. One where you still know where a wireless user is at all times, and can serve them targeted adds ... and ohhhhhh right look who's forum I am posting on.
Third SLAAC plus security extensions becomes and internal security nightmare for Big IT. Only the local router knows the actual MAC. ::HOSTID is randomly changing for every computer per hour or application. How can the firewall keep track of UDP hole punching vs proper use? How can the web filter allow marketing to benchmark there ads versus competition, but also prevent other employees from wasting time watching racy beer commercials? How does R&D and your partner University fellow keep a secure connection to the lab?
First and foremost against pure SLAAC, nobody wants their MAC on the public internet (::HOSTID = MAC with special insert). When your market research team goes on a road trip, then there activity at home can be correlated with trip data, and that's just giving away product futures to corporate espionage.
Second even alternate permanent SLAAC assignment like making up a random one during OS install, creates a world wide track-able machine. One where you still know where a wireless user is at all times, and can serve them targeted adds ... and ohhhhhh right look who's forum I am posting on.
Third SLAAC plus security extensions becomes and internal security nightmare for Big IT. Only the local router knows the actual MAC. ::HOSTID is randomly changing for every computer per hour or application. How can the firewall keep track of UDP hole punching vs proper use? How can the web filter allow marketing to benchmark there ads versus competition, but also prevent other employees from wasting time watching racy beer commercials? How does R&D and your partner University fellow keep a secure connection to the lab?
vf...@pureweb.com <vf...@pureweb.com> #68
Just enabled DHCPv6 in a test IPv6 network. My Android developers couldn't get an IP address. iOS, Windows are just fine. I just learned of Google's position on this matter today.
If you don't understand why I as a network admin would want to control the IP address of the devices on my network, you should get out more. Don't force your implementation of IPv6 down the throats of small IT shops. I don't have time to set up alternate solutions just for one type of mobile device. Also, you should consider IT auditing requirements for many, many industries.
In researching IPv6 over the past few weeks, one thing that stood out was having my device's IP address made publicly available. Devices hide behind firewalls and NATs for a reason. I'm here to protect my employees from attacks with firewalls and utilize NAT as an extra layer of obscurity. Stateless doesn't cut it. Behind the firewall is my DHCP server and pushing out DHCPv6 addresses helps me to track, audit, troubleshoot and provide a sense of order on my network.
You are creating an unnecessary burden to all.
If you don't understand why I as a network admin would want to control the IP address of the devices on my network, you should get out more. Don't force your implementation of IPv6 down the throats of small IT shops. I don't have time to set up alternate solutions just for one type of mobile device. Also, you should consider IT auditing requirements for many, many industries.
In researching IPv6 over the past few weeks, one thing that stood out was having my device's IP address made publicly available. Devices hide behind firewalls and NATs for a reason. I'm here to protect my employees from attacks with firewalls and utilize NAT as an extra layer of obscurity. Stateless doesn't cut it. Behind the firewall is my DHCP server and pushing out DHCPv6 addresses helps me to track, audit, troubleshoot and provide a sense of order on my network.
You are creating an unnecessary burden to all.
wo...@gmail.com <wo...@gmail.com> #69
This bugzilla is getting kind of long in the tooth, but I'd like to add one more reason for supporting dhcp6: Prefix Delegation. An android phone isn't going to be a good tethering gateway if it can't supply routable IPv6 addresses to its downstream devices. Just food for thought...
tr...@go-text.me <tr...@go-text.me> #70
Bump, Status is NOT 'released', it's an incomplete implementation and ipv6 only networks are not supported fully.
We need proper support of ipv6 only networks, even when they use dhcpv6...
We need proper support of ipv6 only networks, even when they use dhcpv6...
ed...@gmail.com <ed...@gmail.com> #71
We need proper support of ipv6 only networks!!!!!
ts...@t-online.de <ts...@t-online.de> #72
Closing this issue might be correct, because in ONE ipv6-only-setup it works indeed.
But there are more than one different network-setups in the world.
So I think the discussion should be continue here:
https://code.google.com/p/android/issues/detail?id=32621
But there are more than one different network-setups in the world.
So I think the discussion should be continue here:
ti...@gmail.com <ti...@gmail.com> #73
Hey Thomas (like I said somewhere else, you're everywhere regarding IPv6 ;-) ),
so in which IPv6-only setup does it work? I tried to connect my phone (Android N) to an IPv6-only WiFi with SLAAC. No DHCPv4 running. Therefor, it'll end the connection after not receiving an IPv4 (setting IPv4 manually to some madeup value is possible as a workaround though).
So in the end, I feel like this issue is still at hand!
so in which IPv6-only setup does it work? I tried to connect my phone (Android N) to an IPv6-only WiFi with SLAAC. No DHCPv4 running. Therefor, it'll end the connection after not receiving an IPv4 (setting IPv4 manually to some madeup value is possible as a workaround though).
So in the end, I feel like this issue is still at hand!
ts...@t-online.de <ts...@t-online.de> #74
As of writing my latest comments it was only tested with my home environment (AVM fritzbox, with special Setup: DNS was a public DNS64-service, IPv4 disabled).
In the meantime I checked it also on my working place. The superordinate IT-department of my working place was for a long time a victim of the cisco-bug (not supporting RFC 8106/6106/5006) but now the big blocking things are solved. Windows (10 1703) supports RFC 8106 as well cisco and android do.
(ios not to forget)
Only companies with demand to assign addresses via DHCPv6 still have a problem with unmodified android devices.
In the meantime I checked it also on my working place. The superordinate IT-department of my working place was for a long time a victim of the cisco-bug (not supporting RFC 8106/6106/5006) but now the big blocking things are solved. Windows (10 1703) supports RFC 8106 as well cisco and android do.
(ios not to forget)
Only companies with demand to assign addresses via DHCPv6 still have a problem with unmodified android devices.
sh...@gmail.com <sh...@gmail.com> #75
I am still seeing the same issue described in #19 and #22 .
Though this issue is marked as fixed, We are still unable to connect to ipv6-only wireless network.
This needs to be reopened.
Though this issue is marked as fixed, We are still unable to connect to ipv6-only wireless network.
This needs to be reopened.
wo...@gmail.com <wo...@gmail.com> #76
Which Android Version are you using? Haven't had any problem with Android and IPv6-only network for a while and FOSDEM Network worked fine as well this year (Pixel 1, Android 9)
sh...@gmail.com <sh...@gmail.com> #77
I tried on same
Pixel(Android Pie) and Pixel 3XL(Android Q)
Every time it gets struck on Obtaining IP address. . .
Tried giving static IPV6 address but I'm unable to save it. . .
Is there any documentation where I can get how to manually assign static ipv6 address on an Android device?
Pixel(Android Pie) and Pixel 3XL(Android Q)
Every time it gets struck on Obtaining IP address. . .
Tried giving static IPV6 address but I'm unable to save it. . .
Is there any documentation where I can get how to manually assign static ipv6 address on an Android device?
sh...@gmail.com <sh...@gmail.com> #78
Still broken,
Can anyone help me here?
Can anyone help me here?
al...@gmail.com <al...@gmail.com> #79
I tried to configure DHCPv6 in my home network lately, only to find that the dhcpv6 is not supported, and dhcpv6 patches were rejected. i cannot believe that L is still full of energy to anger half of world's networking engineers.
ch...@chaz6.com <ch...@chaz6.com> #80
This is marked as fixed however I am unable to connect to an IPv6-only network with Android 10.
ch...@chaz6.com <ch...@chaz6.com> #81
Never mind, this is a local problem. Sorry for the noise.
ks...@usp.br <ks...@usp.br> #82
Almost 12 years since this thread was posted and the problem remains.
Has anyone found any solution?
Has anyone found any solution?
ma...@gmail.com <ma...@gmail.com> #83
You might like to see "Mission Possible: Turning off IPv4 in Google Enterprise Network" by Jen Linkova from last RIPE87 meeting at https://ripe87.ripe.net/archives/video/1160/
br...@gmail.com <br...@gmail.com> #84
Android will be out of professional usages soon in France because of that
problem.
Le jeu. 7 déc. 2023, 04:20, <buganizer-system@google.com> a écrit :
problem.
Le jeu. 7 déc. 2023, 04:20, <buganizer-system@google.com> a écrit :
Description
If attempting to connect to a wireless network that are providing only IPv6 connectivity through Stateless Address Auto-Configuration (RFC 4862), the Android device will successfully associate with the access point, acquire an IPv6 address and a default route, and be fully connected to the network/internet.
However, this connectivity only last while the Android device is still waiting for DHCPv4 reponses. When it gives up waiting, it will deassociate from the access point, tearing down the IPv6 connectivity in the process. After a short cool-off period, it will re-try the connection, repeating the process seemingly indefinitely.
IPv6 has no intrinsic dependeny on IPv4, so IPv6-only is a perfectly valid network configuration. Android should ideally treat IPv4 and IPv6 connectivity as a logical OR; if either (or both) succeeds, the Android device should consider this a overall network connetion success.
Note that in order for an IPv6-only network connection to be useful, it would also be necessary to make it possible for Android to learn IPv6 DNS servers (see issues #32621 and #32629).