4 ms·

> One of the many things that would speed up adoption is "IPv6 by default". This is precisely why I end up searching for the knob to turn off IPv6 in kernel af

by clarry 7y ago

> One of the many things that would speed up adoption is "IPv6 by default". This is precisely why I end up searching for the knob to turn off IPv6 in kernel after installing a new system. That is, if I remember to do so. And then I curse because the system's (or application's) name resolver still keeps performing AAAA queries and breaking because IPv6 doesn't actually work. Recent example: https://bugzilla.mozilla.org/show_bug.cgi?id=1582686 https://bugzilla.mozilla.org/show_bug.cgi?id=1582686 Please don't enable anything by default unless it's actually working.

IcePic 7y ago
> Please don't enable anything by default unless it's actually working Then again, we know news of v4 running out and v6 being the only usable replacement has been running for .. 20 years? If people start _now_ and test what v6 means, then we get what we deserve. Not pointing only to you, but equally the server ends mentioned in this thread also. IANA released its last allocations 8 years ago, how much more forewarning do people need in order to actually move their butts? If you get v6 issues today, it is only because people put their heads in the sand and decided "hey, I have this one machine with a v4 on which I can serve data, I don't need to worry about this issue ever". Having to fiddle with do-or-do-not-resolve-v6 to make stuff work is something we should have spent time on in 2003 or so.
- clarry 7y ago
  > Having to fiddle with do-or-do-not-resolve-v6 to make stuff work is something we should have spent time on in 2003 or so. Agree. The difficulty is that the internet is big and has too many actors, so it's impossible to get everyone on board to plan the roll out. So the next option of just chaotically enabling things here and there without carefully designed fallbacks or coordination in the larger ecosystem is causing precisely the issues that make people scream and look for the switch to turn it all off. It's pretty crazy if you think. I don't think anyone's deploying large production systems with so little coordination and so much random switch flipping by different unrelated (but nevertheless interconnected and interdependent) parties. I can't imagine why the largest big system on planet earth would just work if people do that.
- magicalhippo 7y ago
  > IANA released its last allocations 8 years ago, how much more forewarning do people need in order to actually move their butts? IPv6 feels like the tech version of climate change. Requires too many to do too much with no or negative short-term payout.
  - umanwizard 7y ago
    The payout is not negative. ISPs, especially mobile ones, are rewarded for turning on IPv6 because IPv4 addresses are expensive and CGNAT causes a host of issues for customers.
Jonnax 7y ago
https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html One third of traffic into Google comes from IPv6 sources. And they work fine. When major ISPs around the world are enabling for both their fixed and mobile customers and not getting issues. The problem is either in your ISP, your network or client configuration.
- clarry 7y ago
  > The problem is either in your ISP, your network or client configuration. Thank you for telling me that it's broken. That's kinda my point. Again, I don't have IPv6 connectivity to the world, at all. Random applications trying to enable and use it per default is bound to fail.
  - Jonnax 7y ago
    You linked to a bug in Firefox Nightly. That's hardly indicative of there being widespread issues. Also that bug seems to occur when IPv6 is disabled in the kernel. Random applications should be fine with trying the IPv6 address, and if it fails using the IPv4 address. That should happen transparently. There are millions of Linux deployments that don't require manually disabling IPv6. You not having an IPv6 address is a separate issue.
  - Dagger2 7y ago
    If you don't have v6 connectivity, then by default DNS lookups will be sorted so that v4 addresses are first. I don't know what went wrong in your case, but I don't think it had anything to do with IPv6. `getent hosts` returns v6 addresses (only, no v4) if any exist on the hostname you give it, and thus its output is useless for debugging here. You need to check `getent ahosts <hostname>`, which uses the same getaddrinfo() call that most software (including Firefox) uses for DNS lookup. If you have no v6 connectivity then the v4 addresses should be sorted first in the output of that, and v4 will be tried first by your software. Another good test is `wget <url>` which prints the IPs in sorted order (limited to the first 3 though), tries to connect to them one by one and prints any errors it encounters. If `getent ahosts` is showing v6 addresses sorted first, I'd be happy to take a look at your config -- if you pastebin the output of `ifconfig` and /etc/gai.conf then I should be able to tell you what's up. Either you'll have a v6 address you didn't notice or you've somehow configured your system to sort them first even when you only have v4. For some reason, there's a "I saw a colon somewhere, therefore it's IPv6's fault" trap that people keep falling into. Your posts look like an example of that.
deathanatos 7y ago
This just isn't how dual stacks that are only able to obtain an IPv4 address work. For DNS, if your device decides to perform a AAAA lookup (despite not having an IPv6 address), it would succeed just fine, even over an IPv4 connection. (You can query any record type over the DNS connection/protocol, regardless.) If your device attempted to connect to the resulting address (I don't think most would, but let's assume) it would instantly fail, as there wouldn't be a route to that destination, and fall back to the next record — the A/IPv4 record. There are literally millions of dual stack laptops, phones, tablets, etc. all out there on backwater residential ISP networks that have no idea what IPv6 is. If dual stack didn't work — it'd be a real bug that would have long since been fixed. Similarly, if a dual-stack device had issues transitioning between dual-stack networks and IPv4 networks, we'd also know, as many phones and laptops do this all day. (E.g., my home network was dual-stack, but my work is not. Laptops — and using multiple OSes, too — moving between those networks can auto-configure themselves appropriately.) Like other posters are telling you: if you have a device that has issues when IPv6 is enabled, you have some sort of localized issue with your network setup.
peterwwillis 7y ago
There's no way to know for sure if it works unless we start enabling it and look for these weird edge cases. We should be fixing the bugs we find during this process. That's why IPv6 adoption is painful, and why I think documentation would help a lot. Check if you have options inet6 set in your /etc/resolv.conf, and remove the option if you do. You can also try setting options single-request and options single-request-reopen. Note that the latter two violate the "don't enable it if it's not working" principle; broken middleboxes are screwing with your client, so if these middleboxes were never fixed, we could never use IPv6. Instead we have shitty workarounds. Sometimes that's just the best option available.

by clarry 7y ago

IcePic 7y ago

> Please don't enable anything by default unless it's actually working Then again, we know news of v4 running out and v6 being the only usable replacement has been running for .. 20 years? If people start _now_ and test what v6 means, then we get what we deserve. Not pointing only to you, but equally the server ends mentioned in this thread also. IANA released its last allocations 8 years ago, how much more forewarning do people need in order to actually move their butts? If you get v6 issues today, it is only because people put their heads in the sand and decided "hey, I have this one machine with a v4 on which I can serve data, I don't need to worry about this issue ever". Having to fiddle with do-or-do-not-resolve-v6 to make stuff work is something we should have spent time on in 2003 or so.

clarry 7y ago
> Having to fiddle with do-or-do-not-resolve-v6 to make stuff work is something we should have spent time on in 2003 or so. Agree. The difficulty is that the internet is big and has too many actors, so it's impossible to get everyone on board to plan the roll out. So the next option of just chaotically enabling things here and there without carefully designed fallbacks or coordination in the larger ecosystem is causing precisely the issues that make people scream and look for the switch to turn it all off. It's pretty crazy if you think. I don't think anyone's deploying large production systems with so little coordination and so much random switch flipping by different unrelated (but nevertheless interconnected and interdependent) parties. I can't imagine why the largest big system on planet earth would just work if people do that.
magicalhippo 7y ago
> IANA released its last allocations 8 years ago, how much more forewarning do people need in order to actually move their butts? IPv6 feels like the tech version of climate change. Requires too many to do too much with no or negative short-term payout.
- umanwizard 7y ago
  The payout is not negative. ISPs, especially mobile ones, are rewarded for turning on IPv6 because IPv4 addresses are expensive and CGNAT causes a host of issues for customers.

Jonnax 7y ago

https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html One third of traffic into Google comes from IPv6 sources. And they work fine. When major ISPs around the world are enabling for both their fixed and mobile customers and not getting issues. The problem is either in your ISP, your network or client configuration.

clarry 7y ago
> The problem is either in your ISP, your network or client configuration. Thank you for telling me that it's broken. That's kinda my point. Again, I don't have IPv6 connectivity to the world, at all. Random applications trying to enable and use it per default is bound to fail.
- Jonnax 7y ago
  You linked to a bug in Firefox Nightly. That's hardly indicative of there being widespread issues. Also that bug seems to occur when IPv6 is disabled in the kernel. Random applications should be fine with trying the IPv6 address, and if it fails using the IPv4 address. That should happen transparently. There are millions of Linux deployments that don't require manually disabling IPv6. You not having an IPv6 address is a separate issue.
- Dagger2 7y ago
  If you don't have v6 connectivity, then by default DNS lookups will be sorted so that v4 addresses are first. I don't know what went wrong in your case, but I don't think it had anything to do with IPv6. `getent hosts` returns v6 addresses (only, no v4) if any exist on the hostname you give it, and thus its output is useless for debugging here. You need to check `getent ahosts <hostname>`, which uses the same getaddrinfo() call that most software (including Firefox) uses for DNS lookup. If you have no v6 connectivity then the v4 addresses should be sorted first in the output of that, and v4 will be tried first by your software. Another good test is `wget <url>` which prints the IPs in sorted order (limited to the first 3 though), tries to connect to them one by one and prints any errors it encounters. If `getent ahosts` is showing v6 addresses sorted first, I'd be happy to take a look at your config -- if you pastebin the output of `ifconfig` and /etc/gai.conf then I should be able to tell you what's up. Either you'll have a v6 address you didn't notice or you've somehow configured your system to sort them first even when you only have v4. For some reason, there's a "I saw a colon somewhere, therefore it's IPv6's fault" trap that people keep falling into. Your posts look like an example of that.

deathanatos 7y ago

This just isn't how dual stacks that are only able to obtain an IPv4 address work. For DNS, if your device decides to perform a AAAA lookup (despite not having an IPv6 address), it would succeed just fine, even over an IPv4 connection. (You can query any record type over the DNS connection/protocol, regardless.) If your device attempted to connect to the resulting address (I don't think most would, but let's assume) it would instantly fail, as there wouldn't be a route to that destination, and fall back to the next record — the A/IPv4 record. There are literally millions of dual stack laptops, phones, tablets, etc. all out there on backwater residential ISP networks that have no idea what IPv6 is. If dual stack didn't work — it'd be a real bug that would have long since been fixed. Similarly, if a dual-stack device had issues transitioning between dual-stack networks and IPv4 networks, we'd also know, as many phones and laptops do this all day. (E.g., my home network was dual-stack, but my work is not. Laptops — and using multiple OSes, too — moving between those networks can auto-configure themselves appropriately.) Like other posters are telling you: if you have a device that has issues when IPv6 is enabled, you have some sort of localized issue with your network setup.

peterwwillis 7y ago

There's no way to know for sure if it works unless we start enabling it and look for these weird edge cases. We should be fixing the bugs we find during this process. That's why IPv6 adoption is painful, and why I think documentation would help a lot. Check if you have options inet6 set in your /etc/resolv.conf, and remove the option if you do. You can also try setting options single-request and options single-request-reopen. Note that the latter two violate the "don't enable it if it's not working" principle; broken middleboxes are screwing with your client, so if these middleboxes were never fixed, we could never use IPv6. Instead we have shitty workarounds. Sometimes that's just the best option available.