IPv6 should be disabled by default

I'm setting this bug to confirmed as a lot of users complain about IPv6 slowing down DNS resolution. See https://wiki.ubuntu.com/WebBrowsingSlowIPv6IPv4 if you want to disable IPv6.

I beleieve that ipv6 should be disabled during the installation for the time being and the users should be able to enable it by a single command.

i think the same, im even concidering to change that from wishlist to a normal or major bug, because it is a bug that every time you make a dns request it takes 10-20 seconds.

Agree. This is a big useability issue, lots of people new to Linux/Ubuntu judge the 'slow internet' as a bad point.
And it keeps coming back and back in the discussionforums.

I agree. For instance, removing ipv6 as described in the wiki added an average of 1k to my internet speed. that a plus 1/4 (25%) speed increase in my slow dial up situation which used to be averaging 4k (now 5k).

According to RFC 4472 in 5. Recommendations for DNS Resolver IPv6 Support:

"The third case is a bit more complex: optimizing away the DNS lookups
   with only link-locals is probably safe (but may be desirable with
   different lookup services that getaddrinfo() may support), as the
   link-locals are typically automatically generated when IPv6 is
   enabled, and do not indicate any form of IPv6 connectivity. That is,
   performing DNS lookups only when a non-link-local address has been
   configured on any interface could be beneficial -- this would be an
   indication that the address has been configured either from a router
   advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   [RFC3315], or manually. Each would indicate at least some form of
   IPv6 connectivity, even though there would not be guarantees of it."

Disabling IPv6 increaseing the throughput of your internet connection makes no sense and I think thats just circumstantial, sorry :)

The place where it *does* make a difference is the speed of new connections, it seems that in some cases certain dns servers ignore requests for IPv6 records and so everytime you try to resolve an IPv6 address it waits for them to timeout.

These broken DNS servers should really be fixed, but the last point could work, not to bother looking up, guess it would fix some of these cases.

Could someone who experiences and is willing to let me login to their machine please contact me? I'd love to try this as its never really affected me.

Dear Trent,
> Disabling IPv6 increaseing the throughput of your internet connection
> makes no sense and I think thats just circumstantial, sorry :)
>
> The place where it *does* make a difference is the speed of new
> connections, it seems that in some cases certain dns servers ignore
> requests for IPv6 records and so everytime you try to resolve an IPv6
> address it waits for them to timeout.
>

It is worse than that. In the time it takes for the IPv6 DNS request to
fail the application times out on making its connection.
> These broken DNS servers should really be fixed, but the last point
> could work, not to bother looking up, guess it would fix some of these
> cases.
>

It's not a question of the DNS server being dumb it's usually some cheap
ADSL router/modem that is sitting between the computer and a good DNS
server. Often configuring the router to pass a real DNS server address
to the dhcp client is enough to solve the problem. But not all routers
allow you to configure the dhcp server in them sufficiently.

So perhaps the real fix is to provide a way to turn off IPv6 DNS
requests. But I guess that is impossible without turning off IPv6 in
general. How much IPv6 takes off depends to a large extent on what MS do
with Vista, I would suspect.
> Could someone who experiences and is willing to let me login to their
> machine please contact me? I'd love to try this as its never really
> affected me.
>
I'll send you directly, offline, a couple of tcpdump traces to compare.
One is dns request to the D-Link 504T ADSL modem/router and the other is
directly to a DNS server with packets merely routed by the modem.

On Fri, Jul 28, 2006 at 04:23:11AM -0000, Martin Hosken wrote:
> Dear Trent,
> > Disabling IPv6 increaseing the throughput of your internet connection
> > makes no sense and I think thats just circumstantial, sorry :)
> >
> > The place where it *does* make a difference is the speed of new
> > connections, it seems that in some cases certain dns servers ignore
> > requests for IPv6 records and so everytime you try to resolve an IPv6
> > address it waits for them to timeout.
> >
>
> It is worse than that. In the time it takes for the IPv6 DNS request to
> fail the application times out on making its connection.
> > These broken DNS servers should really be fixed, but the last point
> > could work, not to bother looking up, guess it would fix some of these
> > cases.
> >
>
> It's not a question of the DNS server being dumb it's usually some cheap
> ADSL router/modem that is sitting between the computer and a good DNS
> server. Often configuring the router to pass a real DNS server address
> to the dhcp client is enough to solve the problem. But not all routers
> allow you to configure the dhcp server in them sufficiently.
>
> So perhaps the real fix is to provide a way to turn off IPv6 DNS
> requests. But I guess that is impossible without turning off IPv6 in
> general. How much IPv6 takes off depends to a large extent on what MS do
> with Vista, I would suspect.
> > Could someone who experiences and is willing to let me login to their
> > machine please contact me? I'd love to try this as its never really
> > affected me.
> >
> I'll send you directly, offline, a couple of tcpdump traces to compare.
> One is dns request to the D-Link 504T ADSL modem/router and the other is
> directly to a DNS server with packets merely routed by the modem.
>
> --
> IPv6 should be disabled by default
> https://launchpad.net/bugs/24828

--
Trent Lloyd <email address hidden>
Bur.st Networking Inc.

> It is worse than that. In the time it takes for the IPv6 DNS request to
> fail the application times out on making its connection.

seems ipv6 causes connection issues as in: http://ubuntuforums.org/showthread.php?t=258686 though I'm not sure if that's a problem with the user's router or with the timeout issue as Martin Hosken puts it.

Just my $0.002: I had horrible DNS resolution times ( > 10 seconds ) for a long time and I assumed that it was because my router / ISP didn't support ipv6, so I went through the hassle of turning off ipv6 and the problems that come from that.

This week I decided to switch to openDNS http://en.wikipedia.org/wiki/OpenDNS and to my surprise I had no more DNS resolution problems! So unless you know for sure that your hardware or ISP does not support ipv6, try using another DNS service ( I recommend openDNS as it also has other benefits over traditional DNS services ).

I had strange behavior on NFS mounts via wifi at home, it had high bandwidth in the beginning but then it dropped down, and with delays large enough to forbid watching videos over NFS. Other laptops on the same network have no problems (running dapper), and using other distributions (suse 10.0) on the same laptop I had no such problems too.

Disabling ipv6 seems to have fixed the problem and also to have made google earth work fast. Is this possible or is it a coincidence? My router does not support ipv6. If NFS slowdown are possible this is definitely not only a DNS problem.

Please raise this to critical and schedule into Feisty.

It's critical because it's part of the post-installation user experience and damages Ubuntu's credibility exactly in the eyes of those whom its trying to reach. This bug's been open for 14 months now, and is trivial to fix, so obviously any status below critical isn't going to get attention.

My own experience, I have now found, is typical of many. I'm a hardened Windows user but dislike the prospect of going to Vista. So on a new PC I install Ubuntu. I find Firefox is at best slow, at worst times out on my favourite web pages. It took me _eight hours_ of my own time and involved five members of the Ubuntu community, to get a solution. Of course I did _not_ immediately do a search on IPv6, it simply didn't cross my mind that that could be anything to do with the problem. Instead I just felt stupid, and submitted a stupid newbie report saying my system was slow ... then I sat back waiting for people to ask me whether I'd switched on my monitor etc etc. It shouldn't have to be that way.

I guess the reason why not _everyone_ is afflicted by this problem is that their router kindly suppresses IPv6 before it gets out of their home.

As it happens I work for a company that has IPv6 networking as one of its product features, so I know what IPv6 is. I also know that it's useless for any practical purpose - due to lack of deployment, to lack of consistent implementation, and to feasible alternatives. Yesterday I consulted a senior system architect to confirm that view - it's valid, and nothing is really changing.

I haven't seen a single positive reference to IPv6 in user discussions of Linux (check out the hits in Linux Format forums, for instance).

There are those who think IPv6 will happen some day, and would like a coordinated plan to implement it across the board in Ubuntu (see https://wiki.ubuntu.com/IPv6Integration, for example). I have no problem with this. But it makes sense to disable IPv6 by default, so that conscious experimenters can turn it on if they wish, until such a plan has been worked out in Ubuntu (and rest of world) to enable IPv6 in a way that doesn't create disappointment for any stakeholder.

So the way to fix the problems with an upcoming technology is to supress it? Thats silly.. Disabling it by default out of the box also does not aid adoption.

As far as I can see, this is a limited issue to those with "broken" routers, probably 98% of devices on the market have no problems with this.

Windows Vista is also shipping with IPv6 enabled by default, perhaps this will help weed out the devices which don't do what they are supposed to do and violate the DNS specifications.

It is unfortunate that this is the case, the only solution that I would personally like to see is some kind of attempt at detecting a "broken" router, this could perhaps be achieved by doing a lookup on ubuntu.com for IPv4 only, if that succeeds, try an any lookup and if that is met by serious delays offer the ability to disable it, but I'd love to know exactly how many users are affected by this issue and how much worth there is in spending developer time on this (of course, I'm sure the Ubuntu developers would *consider and discuss* accepting a proper well formed and tested patch that did this) -- perhaps a simple FAQ entry would suffice.

Could those with this problem please tell me what modem manufacturer/model devices you have (and what your dns servers are set to) so I can investigate this further and determine 100% if it is the modem dns servers, or the ISPs servers, etc, if I can login to a box with this problem it would be great...

98% dont have a problem?thats not true. in switzerland 98% of the routers have this problem, just that you know it.

Il giorno mer, 20/12/2006 alle 07.36 +0000, Trent Lloyd ha scritto:
So the way to fix the problems with an upcoming technology is to supress
> it? Thats silly.. Disabling it by default out of the box also does not
> aid adoption.
>
Well, I never liked to be pushed to early adoption of a technology for my everyday work. This is just lying about its stability or well-tested-ness. I don't expect free software to adopt strategies of early-adoption, I can accept that mobile phone companies or processor manufacturers do this, but not a distribution which should be designed for stability, to work well *and* to be customizable, so that i can turn on ipv6 if I find it's better. You can even put a checkbox in the network configuration tool, but I expect the default settings to be maximum safety, not maximum features.

> As far as I can see, this is a limited issue to those with "broken"
> routers, probably 98% of devices on the market have no problems with
> this.
>
>

The observation that one user in my situation can make about ubuntu these days is that "internet is slow". This is the observation that I made on windows 98, seven years ago, and it was embarassing for microsoft. Perhaps also on vista we will see an "internet is slow" problem. The machines on which you are installing ipv6 are home users machines, and you say it's a good idea to make them early adopters? Why? I would rather prefer to see providers adopting ipv6 first, and then home users. Perhaps I don't understand enough of networking to know the advantages of using ipv6, but by now it looks like I can do everything I want without using it. What are the advantages of using ipv6 at home at the moment?

It seems in italy too, we have this problem, but I have a cheap home router so I don't know.

> It is unfortunate that this is the case, the only solution that I would
> personally like to see is some kind of attempt at detecting a "broken"
> router, this could perhaps be achieved by doing a lookup on ubuntu.com
> for IPv4 only, if that succeeds, try an any lookup and if that is met by
> serious delays offer the ability to disable it, but I'd love to know
> exactly how many users are affected by this issue and how much worth
> there is in spending developer time on this (of course, I'm sure the
> Ubuntu developers would *consider and discuss* accepting a proper well
> formed and tested patch that did this) -- perhaps a simple FAQ entry
> would suffice.
>
>
I think it would be better to disable it until a better solution is found. I have seen bugs wait for months an important decision leaving users machines broken, when a quick fix was know, this is not a good idea in my opinion since you already have the update system, and can remove the quick fix and install the true patch anytime you want. You can't know how many people are affected by the problem because normally people do not even know anything about ipv6. Moreover, a FAQ entry does not help newbies that at most can insert a cd and click on "install", and I bet ubuntu wants to cover also this target - at least I hope so. If vista will bring world wide ipv6 adoption, we can wait for this and then turn on by default ipv6 in ubuntu...

Why not just change the Ubuntu installer to query the user for IPv6
support? Jeeeeeeeezzz!
--
Kristian Hermansen

Asraniel - and as I requested, what make/model are the routers that "98% of switzerland" use?

Vicenzo Ciancia wrote: "I think it would be better to disable it until a better solution is found. I have seen bugs wait for months an important decision leaving users machines broken, when a quick fix was known ..."

I agree 100%. And with Vicenzo's other comments.

Trent Lloyd wrote: "Windows Vista is also shipping with IPv6 enabled by default, perhaps this will help weed out the devices which don't do what they are supposed to do and violate the DNS specifications."

This is interesting. Have any Vista users experienced similar problems?

Trent, on your other points, I just can't accept your perspective.

1. IPv6 is far from being imminent. It's been upcoming technology for five years now and it's been realised that IPv4-based NAT etc have solved the IPv6 problems adequately. Ubuntu has no control over the ISPs and routers which don't handle IPv6 properly. What you're effectively asking _me_ is to be committed to driving IPv6 adoption. I'm not! I'm committed to a bunch of other things which is why I've tried Ubuntu, but I did not simultaneously sign up to the IPv6 crusade.

2. in fact, IPv6 was not even something I had thought about (in my personal life - professionally I have had reason to) before installing Ubuntu. I bought a cheap router because I'm not into wasting money, and if I had spent more it would not have been because of IPv6. I didn't use IPv6 as a procurement criterion when selecting my ISP. Surely most users would say the same thing.

3. I am fully aware of the theoretical benefits to the world, of everyone adopting IPv6; But there are currently in practice no user-perceived benefits from using IPv6, and yet many user-perceived disbenefits. Search for IPv6 in Linux Format's forums (at www.linuxformat.co.uk). Every single reference I looked at was negative ("why doesn't this stupid thing work?!"): not one was positive ("I just love Linux because I can use IPv6 at last!!").

Ubuntu is the first thing that's made IPv6 an issue for me. Everything I have read about Ubuntu makes me think that Ubuntu should take this seriously as an inhibitor to adoption. The current default penalizes people who've done nothing stupid.

If you really want to promote IPv6 in the ecosystem, consider making _handling_ IPv6 the default for server configurations of Ubuntu, but _issuing_ IPv4 requests the default for client configurations of Ubuntu. Actually this idea has drawbacks too (essentially because no machine is a pure server, and because people might set up such in their homes) but the point is that it's infrastructure-side where IPv6 adoption has to be driven, not client-side - and especially not home-client-side.

I respect Kristian Hermansen's conciliatory suggestion, but I am not keen on it. It's bad to offer users a choice between options they don't understand. If you offer them such choice, you must of course tell people to select IPv4 unless they really really know what they're doing. My preference would be not to bother, just to disable IPv6 by default, and to offer a FAQ aimed at enabling IPv6 post-install for such users as may wish to.

On 12/20/06, Martin Tasker <email address hidden> wrote:
> I respect Kristian Hermansen's conciliatory suggestion, but I am not
> keen on it. It's bad to offer users a choice between options they don't
> understand. If you offer them such choice, you must of course tell
> people to select IPv4 unless they really really know what they're doing.
> My preference would be not to bother, just to disable IPv6 by default,
> and to offer a FAQ aimed at enabling IPv6 post-install for such users as
> may wish to.

By that same token of advice, why not just disable IPv6 yourself?
http://ubuntuforums.org/showthread.php?t=6841
--
Kristian Hermansen

> By that same token of advice, why not just disable IPv6 yourself?

I have done!

It took me eight hours of my own time, spread over several days, and the involvement of five members of the Ubuntu community on the newbie forum, to work out that I needed to do that.

I would have been seriously more impressed by Ubuntu if I hadn't had to go through all that.

So at this point, I know that every time I do a new install of Linux (Ubuntu or otherwise), the first thing a sensible person does is disable IPv6, then get to work on customizing the desktop to taste etc etc.

What are my options now? (a) disappear safe with my knowledge but let others keep suffering, (b) monitor the newbie forums and help everyone, (c) get the devs to do something to fix the problem, (d) contribute a fix the problem myself or (e) wait for the whole universe to get sorted on IPv6?

I've chosen (c) because it's best for the community, best for me, and the most I can actually do

 Trent Lloyd : most of the people here use "Analog: Netopia" 3346 or "ISDN: Netopia 3356".
This information can be found on the homepage of the biggest swiss ISP:
http://de.bluewin.ch/internetzugang/index.php/endgeraete_adsl

Kristian: we all fixed that ourselves, I personally am worried for newbies who will just not understand why e.g. google earth is unusable on their system, and will trash ubuntu. Many of them will trash GNU/linux "in toto", because ubuntu is nowadays advertised as the "best and easiest to use" linux distribution by many people. Being the latter a good thing, why shouldn't it be really so? Ubuntu is really easy to set up and to use, and apt to newbies, the problem in my opinion is mainly to fix bugs.

If to use ubuntu as they want, newbies must learn how to look for a solution on the web, understand what ipv6 is and how to blacklist kernel modules, you can't surely claim ubuntu is for newbies. Marking this bug as a "wishlist" does not help. It is a serious breakage, not for everybody but for many people.

In any case, discussing it here seems not to be that fruitful, if and when I will have time, I will try to discuss it on the development mailing list.

On 12/23/06, Vincenzo Ciancia <email address hidden> wrote:
> Kristian: we all fixed that ourselves, I personally am worried for
> newbies who will just not understand why e.g. google earth is unusable
> on their system, and will trash ubuntu. Many of them will trash
> GNU/linux "in toto", because ubuntu is nowadays advertised as the "best
> and easiest to use" linux distribution by many people. Being the latter
> a good thing, why shouldn't it be really so? Ubuntu is really easy to
> set up and to use, and apt to newbies, the problem in my opinion is
> mainly to fix bugs.

You make some good points, and I agree. Let me ask you one final
question. How does Microsoft Windows Vista enable IPv6 without making
problems for the end users? Presumably, the Ubuntu users who are
experiencing IPv6 issues would see the same on Vista...
--
Kristian Hermansen

Well, interesting debate. Glad I've made a difference by resurrecting the defect - though getting it put onto the wishlist was not actually what I hoped for!

Perhaps Vicenzo you are right that this needs to go onto a developer discussion, and not just because the defect has been iced. There are real puzzles around. I've done some research, and found that IPv6 is getting another push in the industry - not what I had expected to find. Kristian's question, how does Vista do it, deserves a good answer, and might yield better solutions than merely disabling IPv6 wholesale. I can't personally shed light there - my whole purpose in trying Linux was to avoid Vista!

But I would emphasize that what's at stake here is nothing to do with IPv6. Rather, it's the adoption of consumer Linux, which has an unparalleled opportunity given the disruption which Microsoft is causing with Vista. Ubuntu's reputation makes it a key player in this whole business of Linux adoption.

So the Ubuntu devs in considering this issue are _really_ choosing between being protocol-friendly and being newbie-friendly. I had expected that would be a straightforward call ... but in any case, it's not my call, it's theirs.

That's all from me in this forum until the New Year. Happy Christmas all around (or whatever you're celebrating!).

I personally *suspect* from what I've seen vista would see the same problems, however I don't know, haven't tested, and would be interested to hear from anyone that has tried it.

Also this isn't about IPv6 at all, this is about disabling a potentially usefull feature, to work around broken hardware. (And it is broken, because even if a device doesn't support IPv6, there is no reason to break in this way, it's just lazy coding)

A very simple explanation on why I did set this to wishlist is because there are other users like you that have the exact opposite problems. There is no straight solution to this issue if not complaining to your hw manifacturer or ISP to install some decent compliant software.

The same way I did set to wishlist, I also own the same opposite bug for IPv6 to be initialized even earlier because my ISP does indeed prefer IPv6 over Ipv4.

If any of you can think of a way/solution to make both the setups friendly for both the situation I will be fairly happy to take patches and push them into Ubuntu.

As it stands now I have only see workarounds that don't satisfy both user classes.

Fabio

Disabling and enabling ipv6 is simple, so, given the current transition situation, we should provide a menu entry and a simple dialog to do this.

Regarding choosing the default behavior, I still am inclined towards ipv4, since if you need ipv6, then your ISP will warn you and you will know this, but if you need ipv4 chances are that you never heard about that. If vista will have a great diffusion, I suppose that ISPs will finally switch to ipv6 so that this will be a suitable default. However, given that vista, suse 10.2 already enable it by default, and who knows about fedora and next OSX release, your mileage may vary on the subject.

The problem is caused by buggy caching dns servers in the routers. The IPv4 (!) dns query for a AAAA is simply ignored and not answered so the resolver waits until it timeouts.

You can see this when you do a "host -t AAAA www.kame.net" on a machine behind that router and on any other machine with IPv6 disabled. It should find the AAAA record even with IPv4 only.

In my opinion a better work around than disabling IPv6 would be to manually set a nameserver which is not your router.

Since the problem can be detected automatically (A lookup of a known host with A and AAAA records works, but AAAA gives a timeout) there could be a solution which does one of the following in that case:
a) stop AAAA queries in glibc
b) start a dummy dns server which forwards everything to the real DNS, but answers AAAA queries with a SERVFAIL

I believe that enabling or disabling ipv6 on install or in the network management application should be an option. With appropriate warnings about future compatibility and current performance issues.

In trying out Ubuntu 6.10 Edgy-Eft I found Internet access with Firefox extremely slow to non-existent and I was ready to dump Ubuntu. However being the curious human I am, I decided to not give up. Thanks to the forum list and multiple references to turning off ipv6 through the blacklist I was able to resolve the problem.

My DSL modem only supports basic DHCP and DNS options and has NO support for IPV6 configurations. I found ipv6 to be a problem under Fedora also, so it is not just Ubuntu that is having issues with this problem.

Ubuntu and Linux almost lost a Techie to this problem. Have not doubt that an inexperienced user will dump Linux in a heartbeat if this isn't resolved in the distributions.

DFincher
Info. Sys. Admin

Please remember this has *nothing* to do with whether your modem/router *supports* IPv6, but whether its inherrently broken and doesn't handle DNS queries properly.

I'm not saying this makes it any less of a problem but you must understand its a bug in the devices, they should just pass the DNS requests on properly, I highly expect you'll have exactly the same problem with Vista.

I see a "solution" to this bug. In my opinion, if you need ipv6, your ISP will warn you, and you will know. So, the solution could be blacklisting ipv6 by default, and putting a checkbox in system/administration/network/general to enable it (the module can be loaded on the fly I suppose, so there would even be no need to reboot). I could be happy with enabling it by default, too, but with the same checkbox ready there. Current situation is just a mess where many users will try ubuntu from XP and notice that "internet is slow", and if we are lucky, they will look on the web and find an "evil command line" solution.

On 17/3/07 Trent Lloyd wrote:
> Please remember this has *nothing* to do with whether your modem/router
> *supports* IPv6, but whether its inherrently broken and doesn't handle DNS
> queries properly.

I agree with you 100% on this. I hate to have to find workarounds for poorly developed software and hardware (do it right the first time). I went searching for and found a firmware upgrade to my Actiontec GT701-wg DSL modem and re-enabled IPv6. No more issues with connectivity and speed.

However, I am a technically inclined person who wouldn't think twice about diving head first into a new piece of hardware or software. I have 20+ years of IT experience which I can draw on to resolve issues. A typical user (my wife) would not even know where to start. If Linux (pick your flavor) doesn't work right the first time and isn't easy to troubleshoot the novice user will drop it and run screaming back to 98, XP or Vista (hopefully not WinME).

I really believe the best solution is to limit the possible problems up front. Give the user time to get comfortable with an OS which actually works better and is more stable than anything they have used in the past and then give them options to make it better. Do a check on boot-up for a Live CD and during the installation process for IPv6 timeout. If it exists then place the blacklist-ipv6 file in the modprobe.d directory and let the user enjoy the OS. Secondly place a configuration option in network tools to remove/add the blacklist file at their option. If IPv6 is disabled when the network manager is opened then place a help button which will lead the user to a good descriptive page of how IPv6 can help or limit their Internet experience.

On 17/3/07 Trent Lloyd wrote:
> I'm not saying this makes it any less of a problem but you must understand its
> a bug in the devices, they should just pass the DNS requests on properly, I
> highly expect you'll have exactly the same problem with Vista.

Again, I agree with you 100% on this. You must ask yourself if the normal user would even know how to go look for firmware updates for their hardware. I just about guarantee that if I called my ISP for assistance they would have said something along the lines of "We don't support Linux and can't help you with your problem" and would have never even gotten to the point of identifying a firmware issue as the problem.

Every patch listed for my modem had a disclaimer beside it stating not to use it for Vista. Then after looking a a compatibility chart it appeared that IPv6 would probably be the least of my worries if I wanted to run this modem with Vista.

Ubuntu and Linux have an opportunity and it would be a shame if a small issue such as this limited that opportunity.

Disable IPv6 now and work towards getting a compatibility check in place with clear and simple procedures for the users.

Thanks,
Dfincher

> Disable IPv6 now and work towards getting a compatibility check in place with clear and simple procedures for the users.

IPv6 is used in many university, some company networks. New routers (e.g. the new Apple Airport Extreme) give you an 6to4 address automatically. Disabling would remove an often used feature.

Automatically detecting the router problem at installation is also not possible since many computers move between networks.

I don't think that there is a solution which works without educating the user: manually disabling IPv6 in a GUI when the problem occurs or update the firmware of the user. While the former is easier I think the latter is the better long-term solution.

In any case it would be good if a list of affected routers and firmware versions exists. It would help understanding better how many people are really affected and would be a needed to educate users.

I would be ok with leaving it enabled if there were an easy process to disable it if needed. After doing a little research I did find this to be a prevelent problem with Linux reguardless of distribution. Seems that whatever solution is provided would benefit to any distro which has IPv6 enabled.

Possibly a small troubleshooting app which checks for the IPv6 issue and offers to turn it off if found and recommends that the user look at updating their firmware. Place the with the network managment software. This solution leaves IPv6 enable and provides the user a simple check and disable if desired.

Hardware: Actiontec GT701-wg (sold by Qwest Communications)
Firmware: Version QW05.05 works with IPv6 (Lower versions do not)

Thanks,
DFincher

Thomas, perhaps I don't understand very well the features of ipv6 that you mention. If it was just a matter of additional features, then the solution would be the same as with providing compiz or beryl by default: even if the scale (OSX exposé alike) plugin is really an usability aid, since it shows you all the windows at once, and moreover desktop effects are a good publicity for a linux distribution now that both OSX and Vista have them, ubuntu will not ship compiz by default since it might break things for people having broken opengl support in their video card. I have a card supported by open source drivers and have no such problems, but will not demand compiz by default on ubuntu because I want all newbies to be able to use ubuntu, and don't want them to see a "broken" thing at installation.

The examples you mentioned are university and business, and in both cases you will have a sysadmin or at least basic networking instructions telling you that ipv6 is useful and advising you to enable it. It seems like home users won't really need ipv6 and won't have anyone telling them to check whether ipv6 is breaking things or not - in general. If every case was like that, there would be no reason to enable ipv6 by default. The example brought by Fabio is really interesting: he has a home provider that needs ipv6 enabled. The question is: did they warn you, in their initial instructions, that you needed to enable ipv6? In general, it still seems to me that a provider requiring ipv6 is something rare w.r.t. a provider breaking with ipv6.

Here in France, Tecom AH4222 is distributed by one of the major FAIs, and it suffers from this bug too.

Your reaction to the report is strange. I think we need to allow disabling IPv6 easily, eg via a checkbox in System -> Administration ->Network, along with Avahi enabling option. We could add a tooltip explaining that IPv6 is generating delays and connection errors with buggy routers.This is IMHO compulsory, because a normal user (even advanced users are confused) won't know where to search for a solution. Feisty will suffer from comparison with Windows XP on the *numerous* routers that handle IPv6 badly.

I'm in favor of disabling IPv6 by default since it's still the exception, and that people who use it most often know they use it, and will still be able to use Internet with IPv4. I agree it's good we help passing to IPv6, but Ubuntu's worldwide influence in this domain is little, and people who own buggy routers will still have them. We should always focus on usability: we don't have to force the user to use new technologies if they can bring issues. They should at least be proposed to disable it easily.

Why even no workaround was found in more than a year ?! Now Feisty is to be released, and for at least 6 month people coming from Windows as well as old Linux users will have to bear a slow connection.

Fixed in feisty by blacklisting ipv6

Ubuntu had IPv6 enabled for a long time. Now all other major OS (Vista, OSX) have enabled it by default and Ubuntu will disable it without warning for existing users?

2 things:

1) a change to ifupdown has been done so that current setups will not break (or shouldn't)

2) information to the Release note will be added as soon as somebody from the doc team can tell me where they did move the page.

Fabio

It is worth noting while the ifupdown changes will cause any static setups to continue working, it will break setups relying on autoconfiguration, which are quite common for those using IPv6.

Yes.. hence we need the ReleaseNote.. there is no other way around that without a lot of magic that can behave really badly.

Fabio

This is the most BS solution that I have seen in a while. I understand that the technology is in its infancy, but disabling it is not the right solution either.

In any case, I see your point.

Now for those of you who DO use ipv6 and care, perhaps you have enough knowledge to simply enable the thing again:

#> cat /etc/modprobe.d/blacklist-ipv6
# never load ipv6 automatically. ifupdown will do it for on request.
#blacklist ipv6

ifdown/ifup your interface and you are back in business.

Now let's move on to other bugs that need to be fixed.

as explained on IRC, repeating here again i can add docs to the ReleaseNotes...

this change comes in combo with ifupdown that will do the right thing once you have at least one instance that requires ipv6.

it's the easiest solution that makes everybody happy.

Fabio

Most of the beneficiaries of this change won't notice it. So let me say "thank you" here.

Thanks to the developers for taking this action.

Thanks to those established users who know that IPv6 is an issue, for making a small sacrifice to help out new users - like me - who don't know that.

It's much appreciated.

> this change comes in combo with ifupdown that will do the
> right thing once you have at least one instance that
> requires ipv6.

ifupdown won't be able to know if I need ipv6 since ipv6 uses auto-configuration when a router advertisement arrives and some applications use link-local addresses which are never configured.

Thomas, that's exactly what i told you.. just add a line like:

iface lo inet6 manual

to interfaces and you are done. no other changes.. everything will just work from there on.. loading ipv6, autoconf and etc.

Fabio

Should there be a change in the default interfaces file so that it includes a commented IPv6 line to allow easier enabling of IPv6 support?

Sami: good suggestion. I will see if i can get it done asap.

Fabio

Sami: done thanks. the comment should be there from the monday install CD's or tomorrow network installations.

Fabio

Maybe I'm missing the documentation, but with the exception of the Firefox resolution thing, has anyone worked out why when v6 is enabled DNS resolution is taking so much longer in these cases?

I have installed Ubuntu on many machines, none accessing a v6 network.. and yet none seem to have this problem?

Scott: the problems are 2. hardware that people are forced to use and broken ISP DNS.

once you load ipv6, the glibc resolver will query AAAA first and A later as specified by Internet RFC's.

so when your application (clearly FF is the first one to really show it) attempts to connect to www.foo.bar, the first query will be
AAAA and that one will take ages to fail because of the broken hw/DNS that's not under ubuntu s control. As soon as the timeout
occurs, the resolver will try IPv4 and bang... it works.

the FF "solution" is just to force FF to do a specific A query.

The really worst part here is that these devices and software implementation are not even IPV4 compliant since if you have never configured IPv6, the DNS query will happen
in ipv4.

Fabio

I have serious doubts that blacklisting IPv6 really solves the problem. glibc's getaddrinfo() will still query AAAA regardless, unless AI_ADDRCONFIG flag is set. And it is very often *not* set, if only because it is a "proprietary" GNU extension.

In other words, the problem is now fixed merely for some applications, but surely not all of them, and particularly probably a bunch of apps in Ubuntu universe.

IMHO, the proper solution would rather go along the lines of what MacOS X does, i.e. only try AAAA if there is any non-loopback non-link-local IPv6 address (and only try A is there is any non-loopback IPv4 address). That means hacking glibc, and has nothing to do with the *kernel* IPv6 plugin. Also, I think it is much less likely that an application will want to resolve AAAA in absence of IPv6 connectivity, than it is likely that some Ubuntu users will want IPv6 connectivity, even though both are uncommon situation in any case.

Finally, adding such a blacklist looks like an incoming source of headaches if IPv6 is to ever be restored, and a nice source of Ubuntu bashing from advanced users once Feisty is released.

To sum up, the real problems are that glibc only checks IPv6 connectivity if AI_ADDRCONFIG is set (this is a trivial hack to sysdeps/posix/getaddrinfo.c), and then glibc's check_pf considers IPv6 is available even if there is only ::1 or fe80::something which is clearly wrong (this is a not-so-trivial to make_request from sysdeps/unix/sysv/linux/check_pf.c).

My 0,02€. Regards.

Remi, restoring IPv6 is a matter of adding/uncommenting a line in interfaces or removing the blacklist. I don't believe that it can be such big source of headackes.

What MacOS does is also not completely proper. I can have only link-local address and use them to connect from one machine to another with proper entries
in the DNS. How your solution would address this case if AAAA query will not be available?

Fabio

First my apologies for the initial remark. I did not realize that
getaddrinfo() actually stopped doing AAAA if ipv6 was not loaded even
if AI_ADDRCONFIG was not set.

Answers inline.

Le lundi 2 avril 2007 06:53, Fabio Massimo Di Nitto a écrit :
> Remi, restoring IPv6 is a matter of adding/uncommenting a line in
> interfaces or removing the blacklist. I don't believe that it can be
> such big source of headackes.

So, how do I deploy Ubuntu with IPv6 to a large number of PCs with
non-techies users?

Even if I could modify the configuration manually, how do I cope with
configuration files updates from Ubuntu? dpkg will not deploy new
versions because the configuration files changed.

At the very least, the ipv6 blacklist should be in a file of its own so
that it does not prevent upgrading the rest of the file for people
still using IPv6.

That's not only immensely impractical for "human beings", the current
solution provides no sane exit strategy and upgrade path, which is the
most basic question to answer when deploying this kind of kludge.

Also the statement that this is "not an issue" because it's handled by
ifupdown is misleading. It misses the fact that most IPv6 systems are
using stateless autoconf (but I'm repeating comments already made by
other people).

On my system, the upgrade also had the very unkind effect of breaking
ip6tables completely, since IPv6 autoloading got disabled, and any sane
person will do firewall configuration before configuration the network
interfaces.

> What MacOS does is also not completely proper.

The MacOS X solution is far from perfect, but it is surely much less
worse than permanently killing IPv6 because of a few broken DNS caches.

> I can have only
> link-local address and use them to connect from one machine to
> another with proper entries in the DNS.

Any applications, with the possible exception of ping6, will
return "Invalid argument" error because the DNS resolver cannot
guess/set the scope ID in the IPv6 socket address structure. Futhermore
many applications cannot deal with link-local anyway because they do
not preserve the scope ID even if it's set.

On top of that, putting link-local in the DNS is against documented
standard practices.

> ow your solution would address this case if AAAA query will not be
> available?

The current solution does not handle this case either, in any practical
circumstance.

Regards;

--
Rémi Denis-Courmont
http://www.remlab.net/

Ouch, another comment here to say that blacklisting this broke a perfectly working ipv6 system. I can see doing this for new installs, but I don't think it's a good idea to break existing ones.

The Vista DNS Query Behaviour is described here:

http://www.microsoft.com/technet/network/ipv6/vista_dns.mspx

"- If the host has only link-local or Teredo IPv6 addresses assigned, the DNS Client service sends a single query for A records.
- If the host has at least one IPv6 address assigned that is not a link-local or Teredo address, the DNS Client service sends a DNS query for A records and then a separate DNS query to the same DNS server for AAAA records. If an A record query times out or has an error (other than name not found), the corresponding AAAA record query is not sent."

I don't know why they don't do any AAAA query if you have a teredo address (which is globally routable), but the rest sounds reasonable.

Rémi Denis-Courmont wrote:
> First my apologies for the initial remark. I did not realize that
> getaddrinfo() actually stopped doing AAAA if ipv6 was not loaded even
> if AI_ADDRCONFIG was not set.

no problem :)

>
> Answers inline.
>
> Le lundi 2 avril 2007 06:53, Fabio Massimo Di Nitto a écrit :
>> Remi, restoring IPv6 is a matter of adding/uncommenting a line in
>> interfaces or removing the blacklist. I don't believe that it can be
>> such big source of headackes.
>
> So, how do I deploy Ubuntu with IPv6 to a large number of PCs with
> non-techies users?
>
> Even if I could modify the configuration manually, how do I cope with
> configuration files updates from Ubuntu? dpkg will not deploy new
> versions because the configuration files changed.

/etc/network/interfaces is not considered a configuration file and no packages
owns it. So you can modify it at will.

>
> At the very least, the ipv6 blacklist should be in a file of its own so
> that it does not prevent upgrading the rest of the file for people
> still using IPv6.

It is on its own blacklist file alone.

>
> That's not only immensely impractical for "human beings", the current
> solution provides no sane exit strategy and upgrade path, which is the
> most basic question to answer when deploying this kind of kludge.

Well here we need to balance what are the pros and cons. Pros are a lot given
how many people are unfortunately hitted by broken hw and broken DNS
implementations. Cons is only one.. to re-enable autoconf you need to either
unblacklist ipv6 or add one line to /etc/network/interfaces.

I think the overall price is worth the benefit.

> On my system, the upgrade also had the very unkind effect of breaking
> ip6tables completely, since IPv6 autoloading got disabled, and any sane
> person will do firewall configuration before configuration the network
> interfaces.

I usually load a firewall on given protocol once lo is up on that protocol for 2
reasons:

1) i can make sure the protocol is loaded
2) it is always executed before any real interface is up.

Another way to hook up a firewall script to a specific protocol is to use the
/etc/modprobe.d/ to run a script as soon as a certain module is loaded.

>
>> What MacOS does is also not completely proper.
>
> The MacOS X solution is far from perfect, but it is surely much less
> worse than permanently killing IPv6 because of a few broken DNS caches.

s/caches/implementations and it's not just DNS here. As I said there is also
broken hardware around.

>
>> I can have only
>> link-local address and use them to connect from one machine to
>> another with proper entries in the DNS.
>
> Any applications, with the possible exception of ping6, will
> return "Invalid argument" error because the DNS resolver cannot
> guess/set the scope ID in the IPv6 socket address structure. Futhermore
> many applications cannot deal with link-local anyway because they do
> not preserve the scope ID even if it's set.
>
> On top of that, putting link-local in the DNS is against documented
> standard practices.

It appears somebody is using it this way and it was brought up as use case.
I will check this up again.

F...

Le lundi 2 avril 2007 18:39, vous avez écrit :
> /etc/network/interfaces is not considered a configuration file and no
> packages owns it. So you can modify it at will.

I was referring to the backlist file, not interfaces.

(...)
> I think the overall price is worth the benefit.

You won't think that way when Ubuntu gets dropped in favor of
your-favorite-IPv6-capable-proprietary-OS-here at some big government
agency, in some university campus, or by DVB-H users..., because for
some reason IPv6 ended up on the overhyped requirements list (even if
it won't be used in practice). But I'm getting off-topic

> > On my system, the upgrade also had the very unkind effect of
> > breaking ip6tables completely, since IPv6 autoloading got disabled,
> > and any sane person will do firewall configuration before
> > configuration the network interfaces.

> I usually load a firewall on given protocol once lo is up on that
> protocol for 2 reasons:

I don't. Is it a reason to break my working system?

Besides, it does not work either, since there were no need to set inet6
explicitly on lo so far.

> 1) i can make sure the protocol is loaded

ip6tables normally autoloads IPv6, which is the only sensical thing it
could do.

> 2) it is always executed before any real interface is up.

That's a side effect. In practice, lo is created by the kernel, and the
lo interface in /etc/network/interfaces is really a cosmetic entry.

> Another way to hook up a firewall script to a specific protocol is to
> use the /etc/modprobe.d/ to run a script as soon as a certain module
> is loaded.

If ipv6 gets loaded after some real interface is brought up, we get an
unfirewalled time window, which was the precise reason for not doing it
that way.

> >> What MacOS does is also not completely proper.
> >
> > The MacOS X solution is far from perfect, but it is surely much
> > less worse than permanently killing IPv6 because of a few broken
> > DNS caches.
>
> s/caches/implementations and it's not just DNS here. As I said there
> is also broken hardware around.

It *is* only DNS, or pre-2.6.9 kernels with the default onlink
assumption. Feisty has 2.6.20 plus glibc 2.5 with proper RFC3484
support.

> It appears somebody is using it this way and it was brought up as use
> case. I will check this up again.

It appears many more people are using IPv6 and expect it to work out of
the box on their Ubuntu Feisty, as it did in Dapper and Edgy. From
reading the bug thread and the rants on freenode/#ipv6, I have a
feeling I am not the only one.

18:44 remi@auguste ~% host basile.link
basile.link has IPv6 address fe80::211:11ff:fe25:e6b4
18:44 remi@auguste ~% ssh basile.link
ssh: connect to host basile.link port 22: Invalid argument
18:44 remi@auguste ~% ssh basile.link%eth0
ssh: basile.link%eth0: Name or service not known
18:44 remi@auguste ~% ping6 basile.link
connect: Invalid argument
18:44 remi@auguste ~% ping6 basile.link -I eth0 -c 1
PING basile.link(basile.link) from fe80::20d:60ff:fe38:6d16 eth0: 56
data bytes
64 bytes from basile.link: icmp_seq=1 ttl=64 time=0.167 ms

--- basile.link ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/a...

Howdy,

<snip>
>>> breaking ip6tables completely, since IPv6 autoloading got disabled,
>>> and any sane person will do firewall configuration before
>>> configuration the network interfaces.
> On my system, the upgrade also had the very unkind effect ofI usually
> load a firewall on given protocol once lo is up on that protocol for 2
> reasons
> I don't. Is it a reason to break my working system?
>
> Besides, it does not work either, since there were no need to set inet6
> explicitly on lo so far.
>
I have to say I am somewhat in agreeance that this should potentially be
made to apply "only to new installs", because it can break existing
machines that are only available via IPv6, etc.

<snip>
>> 2) it is always executed before any real interface is up.
>>
>
> That's a side effect. In practice, lo is created by the kernel, and the
> lo interface in /etc/network/interfaces is really a cosmetic entry.
>
That is not correct, the kernel creates 'lo' just like it creates eth0,
eth1, etc, but it does not configure an IP.
This is what that stanza does.
>
>> Another way to hook up a firewall script to a specific protocol is to
>> use the /etc/modprobe.d/ to run a script as soon as a certain module
>> is loaded.
>>
>
> If ipv6 gets loaded after some real interface is brought up, we get an
> unfirewalled time window, which was the precise reason for not doing it
> that way.
>
Put lo before any other interfaces in 'auto' and that should not happen
AFAIK.

<snip>
>> It appears somebody is using it this way and it was brought up as use
>> case. I will check this up again.
>>
>
> It appears many more people are using IPv6 and expect it to work out of
> the box on their Ubuntu Feisty, as it did in Dapper and Edgy. From
> reading the bug thread and the rants on freenode/#ipv6, I have a
> feeling I am not the only one.
>
> 18:44 remi@auguste ~% host basile.link
> basile.link has IPv6 address fe80::211:11ff:fe25:e6b4
> 18:44 remi@auguste ~% ssh basile.link
> ssh: connect to host basile.link port 22: Invalid argument
> 18:44 remi@auguste ~% ssh basile.link%eth0
> ssh: basile.link%eth0: Name or service not known
> 18:44 remi@auguste ~% ping6 basile.link
> connect: Invalid argument
> 18:44 remi@auguste ~% ping6 basile.link -I eth0 -c 1
> PING basile.link(basile.link) from fe80::20d:60ff:fe38:6d16 eth0: 56
> data bytes
> 64 bytes from basile.link: icmp_seq=1 ttl=64 time=0.167 ms
>
> --- basile.link ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.167/0.167/0.167/0.000 ms
>
> ping6 is the only application that can handle this, which is of pretty
> limited use. Also, when you're down to doing link diagnostics, you
> probably cannot reach the DNS server, so you'd better use numerical
> addresses anyway.
>
Link local addresses aren't limited to just "link diagnostics", also
when using avahi/zeroconf, you may well have dns for just the local link.

It is true, and somewhat annoying, that using link local IPs require
interfaces to be specifically set, some applications will do this, some
won't, this is an ongoing issue in relation to Avahi right now.

<snip>

Che...

Has anyone affected by this tried this in feisty? Apparently there may be some changes in glibc 2.5 which affect this?

Trent

> Link local addresses aren't limited to just "link diagnostics", also
> when using avahi/zeroconf, you may well have dns for just the local link.

I am no avahi expert so I could be wrong. I think avahi/zeroconf only
uses the dns protocol, but won't use the glibc name resolution functions
with link local addresses. So this use case won't affect the Vista/OS X
like name resolution.

The relevant changes in glibc 2.5 are address sorting related. I don't think
it allows disabling AAAA queries in gai.conf

From glibc NEWS:

* For Linux, the sorting of addresses returned by getaddrinfo now also
  handles rules 3, 4, and 7 from RFC 3484. I.e., all rules are handled.
  Implemented by Ulrich Drepper.

* Allow system admin to configure getaddrinfo with the /etc/gai.conf file.
  Implemented by Ulrich Drepper.

gai.conf man page:

http://www.die.net/doc/linux/man/man5/gai.conf.5.html

Thomas Butter wrote:
>> Link local addresses aren't limited to just "link diagnostics", also
>> when using avahi/zeroconf, you may well have dns for just the local link.
>>
>
> I am no avahi expert so I could be wrong. I think avahi/zeroconf only
> uses the dns protocol, but won't use the glibc name resolution functions
> with link local addresses. So this use case won't affect the Vista/OS X
> like name resolution.
>
Well, I am ;)

I was talking about situations where you could be using a link local IP,
that is in DNS, where you may not have a default route.

Case in point was Avahi which can make use of link local IPs which you
can then get at with DNS using the libnss-mdns, having said that given
the interface specification stuff, they are relatively useless unless
your using the Avahi API directly which allows you to get the interface
along with the name.

Cheers,
Trent

<snip>

On Tue, 03 Apr 2007 05:50:13 -0000, Thomas Butter <email address hidden> wrote:
> The relevant changes in glibc 2.5 are address sorting related. I don't
> think it allows disabling AAAA queries in gai.conf

Yes. These changes will NOT AT ALL fix the AAAA timeout problem. But some
people reported there were "other" (unspecified?) issues than AAAA timeout.

glibc 2.5 (and kernel 2.6.17.2) will fix a bunch of other potential
IPv6-related inconviences:
It will not cause connection timeouts when trying to connect to a
dual-stack server from a dual-stack private-IPv6(ULAs) and IPv4 network,
as IPv4 will be attempted first.
Similarly, if you have sone clueless XP/Vista box advertising a 6to4 prefix
on the network: glibc 2.5 will prioritize IPv4 (unless the final destination
has a 6to4 address), whereas glibc 2.3 would prioritize IPv6.

--
Rémi Denis-Courmont
http://www.remlab.net/

>First my apologies for the initial remark. I did not realize that
>getaddrinfo() actually stopped doing AAAA if ipv6 was not loaded even
>if AI_ADDRCONFIG was not set.

Is it true?

Here feisty with libc-2.5.0ubuntu12
no ip6
but wget, for example, still request AAAA records

As I understand it, a patch has now been applied to glibc

"A fixed glibc with the following patch has been uploaded today:

14:30 < Mithrandir> Uploading to ubuntu (via ftp to upload.ubuntu.com):
glibc_2.5-0ubuntu13.dsc: done. glibc_2.5-0ubuntu13.diff.gz: done.
glibc_2.5-0ubuntu13_source.changes: done.

This glibc has the following patch in it:
http://err.no/patches/glibc-only-lookup-ipv6-if-it-makes-sense.diff

Mithrandir is Tollef Fog Heen, Ubuntu Release Manager.

"

Which should fix this issue in a much better way - will this hack now be reverted?

Yes the blacklist has been removed already.

Fabio

Rock, I really do feel this is the right solution

I guess at the end of the day your blacklisting kicked enough upraw to fix the problem, so I guess it was the right move :)

Cheers!
Trent

Thanks for the good fix!

This bug is back in gutsy. The patch should be applied again.

David: I've re-raised this as bug 156720 and a fix is in progress. Thanks.

Thomsas Butter wrote:
> Thanks for the good fix!

Is my understanding correct that even this fix does not solve the problem for all applications?

Henning Moll wrote:
> Is my understanding correct that even this fix
> does not solve the problem for all applications?

Of course, it does not solve the problem for applications calling the resolver explicitly with AF_INET6. That's bound to fail. These applications would fail worse if libc behavior were changed on that one.