Bug#268631: force preference of IPv4 over IPv6
The basic idea is that we want to make sure that either there's no IPv6 at all, or IPv6 works fine. where by fine you actually mean something much stronger: IPv6 at least as good as IPv4 Okay, let's consider people who want IPv6 but (for whatever reason) cannot ensure that their IPv6 is better than their IPv4. Wouldn't it be a good idea to make their lives a little easier? Eg, /etc/gai.conf could have an accompanying /etc/gai.conf.d/ directory, in the Debian tradition, that would have the files it contains implicitly scanned. This would make it easier to prefer IPv4 in a way that won't require manual intervention on every upgrade. E.g., by including a file /etc/gai.conf.d/prefer-ipv4 containing one line. It would also make it easier for slow-IPv6-provision gizmos, like miredo or aiccu, to indicate that IPv4 is preferred in a way that is easy to automatically turn back off when said systems are disabled. These systems could put a symlink, e.g., /etc/gai.conf.d/aiccu - /var/run/whatever and create/delete the /var/run/whatever file when their slow IPv6 link goes up and down. --Barak. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
There are excellent reasons why IPv6 is preferred to IPv4 by default, and this is not going to change. I'm very interested in this! What are the reasons? The basic idea is that we want to make sure that either there's no IPv6 at all, or IPv6 works fine. This is important, since it's easy to write software that detects and works around the lack of IPv6, but it's next to impossible to write software that will reliably detect broken IPv6. By preferring IPv6 to IPv4, we make sure that broken IPv6 is something that people notice, and hence we have a good chance that there won't be to many broken IPv6 deployments. If IPv4 were preferred to IPv6, then people could add RAs to their network even though their IPv6 routing is broken -- most clients wouldn't notice, they'd just continue using IPv4. Now your particular deployment of IPv6 doesn't fit the ``IPv6 at least as good as IPv4'' model that we are promoting; hence, you need to hack your gai.conf files. Which is fine -- what you do on your private network is your private business. What is not okay is suggesting that Debian change the default, and break a deployment model that the networking community has agreed on -- if you don't agree with a stan- dard, you work on getting it revised, you don't just change your distribution unilaterally. By the way, this is a somewhat unsatisfactory solution: manually hacking /etc/gai.conf doesn't scale. The networking community is aware of that, and are working on a solution -- see RFC 5220 and 5221. Juliusz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
Tagging the bug as wontfix. Aurélien, You've tagged this bug as ``wontfix'' after I renamed it to gai.conf difficult to find While I fully agree with you that the current default should remain, I still think we should point users at gai.conf in a more visible manner. Do I have your permission to un-wontfix this bug? Juliusz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
tag 268631 - wontfix thanks On Mon, Apr 27, 2009 at 11:03:22PM +0200, Juliusz Chroboczek wrote: Tagging the bug as wontfix. Aurélien, You've tagged this bug as ``wontfix'' after I renamed it to gai.conf difficult to find While I fully agree with you that the current default should remain, I still think we should point users at gai.conf in a more visible manner. OK, I haven't seen that. Do you have an idea where to put this info, so that users actually see it? Do I have your permission to un-wontfix this bug? Done with this mail. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
Barak A. Pearlmutter ba...@cs.nuim.ie wrote: Hi, For the next few years at least, when both are available, IPv4 will typically be faster and more reliable than IPv6. That is the world we are living in. In the world I live in, my ISP was among the very first here to deploy native IPv6 on DSL *years* ago and is actively seeking IPv6 peering opportunities with as many networks as possible. IPv6 connections here are usually as fast if not faster than IPv4 connections. I suggest you fix your world instead of insisting on breaking everbody else's by changing a default policy and making it the exact opposite of what everbody else is doing and what the standards recommend. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
In the world I live in, my ISP was among the very first here to deploy native IPv6 on DSL *years* ago and is actively seeking IPv6 peering opportunities with as many networks as possible. That is great. Do they artificially slow down IPv4 in order to ensure that IPv6 is faster? IPv6 connections here are usually as fast if not faster than IPv4 connections. Maybe within their network, but I don't believe this for global connectivity. Periodically measure sustained bandwidth and latency to a distant host at another IPv6-loving ISP, say ftp.ie.debian.org, over both IPv4 and IPv6. That would be a best case scenario. You will not find IPv6 to be faster or more reliable than IPv4. I suggest you fix your world ... That is silly. It will be extremely rare for IPv6 to be *faster* or *more reliable* than IPv4, for quite a while. This is because ISPs have these things called customers who want to access this thing called The Internet by which them mean connecting to hosts like $ for h in www.comedycentral.com www.cnn.com slashdot.org www.ietf.org \ www.google.com www.mit.edu www.yale.edu www.cs.cmu.edu \ www.whitehouse.gov www.army.mil; do for p in a ; do host -t $p $h | egrep address | head -1 done done a1481.b.akamai.net.2b55293e.1.cn.akamaitech.net has address 92.122.124.11 www.cnn.com has address 157.166.255.18 slashdot.org has address 216.34.181.45 www.ietf.org has address 64.170.98.32 www.ietf.org has IPv6 address 2001:1890:1112:1::20 www.l.google.com has address 216.239.59.103 www.mit.edu has address 18.7.22.83 elsinore.cis.yale.edu has address 130.132.51.8 MICHELANGELO.SRV.cs.cmu.edu has address 128.2.203.164 e2561.b.akamaiedge.net has address 92.122.114.135 www1.ahp.us.army.mil has address 143.69.249.10 As you can see, popular server do not provide IPv6 access. Even the rare host that does also provides IPv4 that is at least as performant. ISPs must therefore make it their first priority to make IPv4 fast reliable. Whining at them won't help. What *would* help would be taking technical measures that allow ISPs to field IPv6 without breaking things that already work. And wouldn't it be great if those very same technical measures would also allow servers like those above to advertise an IPv6 address without endangering performance in communicating with IPv6-enabled clients? Then hosts could advertise IPv6 addresses without risk of breaking things that already work. If that were the case, perhaps they would. Then we would have a viable path to an actual transition. --Barak. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
Barak A. Pearlmutter ba...@cs.nuim.ie wrote: Hi, In the world I live in, my ISP was among the very first here to deploy native IPv6 on DSL *years* ago and is actively seeking IPv6 peering opportunities with as many networks as possible. That is great. Do they artificially slow down IPv4 in order to ensure that IPv6 is faster? They actually peer with a high enough number of good IPv6 networks; big telcos are beefing up IPv6-wise and some of them are even deploying IPv6-only networks and peerings. That helps. This kind of thing tends to work best when both sides know their stuff. Here they do. connectivity. Periodically measure sustained bandwidth and latency to a distant host at another IPv6-loving ISP, say ftp.ie.debian.org, over While tracing ftp.ie.debian.org: [...] 6: 2001:450:2002:9f::1 117.317ms asymm 7 7: 2001:450:2002:70::2 1135.219ms asymm 10 [...] Either that's a tunnel and they should get rid of it, or they need a bigger pipe and a bigger router to handle the load. None of this is caused by IPv6, it's just sucky networking. That is silly. It will be extremely rare for IPv6 to be *faster* or *more reliable* than IPv4, for quite a while. This is because ISPs As I wrote above, some v6-only networks are being built, and those will be faster than their v4 counterpart right now due to a lower traffic. www.l.google.com has address 216.239.59.103 % host -t www.l.google.com www.l.google.com has IPv6 address 2001:4860:a004::68 You should do your research better. Google is fully IPv6-enabled, and it took only a ridicule amount of time to an undersized, part-time team of Googlers to make it so. IPv6 addresses without risk of breaking things that already work. If that were the case, perhaps they would. Then we would have a viable path to an actual transition. There is a transition path. It is being rolled out. It works. It's actually easier to embrass IPv6 than it is to work against it. Now if only people realized that. I think you have no solid technical arguments against IPv6. It really seems like you've been molested by a hurd of IPv6 addresses running wild or something. A few years ago, a fair number of bugs were still being worked out in the v6 stacks pretty much everywhere and there were problems. Now it's ancient history and things have been reliable for some time. I've been running dual stack hosts since 2000. It was sometimes unbearable in the first few years, but it's been *ages* since I've had to deal with a v6-induced issue. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
Please understand, I'm a big IPv6 advocate. I use it on all my own machines. It is deployed on some local networks I use. There is extraordinarily strong IPv6 expertise here. The guy who maintains our network (David Malone) literally wrote the book on IPv6 network administration. The host ftp.ie.debian.org is centrally hosted at heanet.ie, which is a centre for IPv6 deployment and expertise, a sixxs tunnel broker, which extends direct IPv6 service to universities here, etc. This kind of thing tends to work best when both sides know their stuff. Here they do. They know their stuff here too. Maybe someone in the middle is messing things up. Maybe something is temporarily or accidentally configured in a suboptimal fashion, somewhere. Maybe some router had a hiccup and its IPv6 stuff went a little sour until someone notices and tickles it. Whatever. The thing is, there is much less pressure to keep the *global* IPv6 network tuned, and sometimes it takes a while for problems to be recognized and repaired. This is not due to malice or deliberate neglect. It is due to the fact that IPv4 problems cause immediate serious blowback, while IPv6 problems do not. It is a chicken-and-egg problem, and ranting about how nice it would be if everyone deployed IPv6 and gave it a lot of tender loving care does not help. None of this is caused by IPv6, it's just sucky networking. OBVIOUSLY! But for the moment, IPv4 problems get recognized and repaired rapidly, and IPv6 problems do not. Why? Chicken-and-egg. No one relies on IPv6 because it is unreliable. Why is it unreliable? Because no one relies on it! ... Google is fully IPv6-enabled Sort of. I've used http://ipv6.google.com/. But Google has IPv6 disabled at the DNS level for www.google.com, albeit perhaps only for some requests. Watch: $ curl --ipv4 --silent --show-error http://www.google.com | wc -c 218 $ curl --ipv6 --silent --show-error http://www.google.com | wc -c curl: (6) Couldn't resolve host 'www.google.com' Why? Because enabling it would break or degrade performance on many IPv6-enabled clients, which would blithely prefer IPv6 and get sporadic service. If the clients defaulted to preferring IPv4, then this wouldn't be a problem, and Google could put IPv6 addresses into all DNS records, without risk. That's what I'd like to see happen. It won't until clients default to prefer IPv4. So Google is your IPv6 poster child? Watch! $ ping -c2 www.google.com PING www.l.google.com (216.239.59.104) 56(84) bytes of data. 64 bytes from gv-in-f104.google.com (216.239.59.104): icmp_seq=1 ttl=237 time=2.57 ms 64 bytes from gv-in-f104.google.com (216.239.59.104): icmp_seq=2 ttl=237 time=2.25 ms $ ping6 -c2 ipv6.google.com PING ipv6.google.com(fx-in-x68.google.com) 56 data bytes --- ipv6.google.com ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms $ timeout 60 telnet ipv6.google.com http Trying 2001:4860:a003::68... Timeout: aborting command ``telnet'' with signal 9 Killed I think you have no solid technical arguments against IPv6. I want to see IPv6 deployed. I'm not making a technical argument against IPv6. What I'm arguing against is making it hard for people to deploy IPv6 by setting up defaults that cause enabling IPv6 to break things! Problems and risks induced by prefer IPv6 are delaying full deployment on both client networks and on servers. What I'm arguing against is default configurations that make it easy for enabling IPv6 to break things. If we instead deliberately make it *hard* for enabling IPv6 to break things, then people will actually enable IPv6. Which is what I want! ... it's been *ages* since I've had to deal with a v6-induced issue. You are lucky; that is quite unusual. But wait: you get much degraded access to ftp.ie.debian.org over IPv6 than over IPv4. So you *do* have an v6-induced issue: degraded service to that particular host. --Barak. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
Barak A. Pearlmutter ba...@cs.nuim.ie wrote: Please understand, I'm a big IPv6 advocate. I wouldn't have guessed. I think it showed, didn't it? administration. The host ftp.ie.debian.org is centrally hosted at heanet.ie, which is a centre for IPv6 deployment and expertise, a sixxs tunnel broker, which extends direct IPv6 service to universities here, etc. Given the problem you point out with this particular host, it's quite ironic, isn't it? What about getting them to fix it? and tickles it. Whatever. The thing is, there is much less pressure to keep the *global* IPv6 network tuned, and sometimes it takes a while for problems to be recognized and repaired. This is not due to malice or deliberate neglect. It is due to the fact that IPv4 problems cause immediate serious blowback, while IPv6 problems do not. Maybe it's because people complain on the BTS that IPv6 is preferred over IPv4 by default and this causes issues with ftp.ie.debian.org instead of telling the folks at Heanet about it? But for the moment, IPv4 problems get recognized and repaired rapidly, and IPv6 problems do not. Why? Chicken-and-egg. No one relies on IPv6 because it is unreliable. Why is it unreliable? Because no one relies on it! Or because people who should know better just shrug at it thinking it's just v6, v4 works, I'll got with that instead of looking at the issue and sending a quick mail to the people in charge? Sort of. I've used http://ipv6.google.com/. But Google has IPv6 disabled at the DNS level for www.google.com, albeit perhaps only for some requests. Watch: Good, so you know about it. I have no problems with the claim that only a minority of mainstream sites are v6-enabled, but I do have a problem when this claim comes with bogus examples. Why? Because enabling it would break or degrade performance on many IPv6-enabled clients, which would blithely prefer IPv6 and get According to their own study, many IPv6-enabled clients is actually a minority. sporadic service. If the clients defaulted to preferring IPv4, then this wouldn't be a problem, and Google could put IPv6 addresses into all DNS records, without risk. That's what I'd like to see happen. It won't until clients default to prefer IPv4. If that was the case I think Google wouldn't be IPv6-enabled today, actually. $ ping6 -c2 ipv6.google.com PING ipv6.google.com(fx-in-x68.google.com) 56 data bytes --- ipv6.google.com ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms What is that supposed to show? That your ISP is not peering with Google like most ISPs do? (if they're peering with Google for v4 already, they really just have to ask their contact for v6 and they'll get it) I think you have no solid technical arguments against IPv6. I want to see IPv6 deployed. I'm not making a technical argument against IPv6. it doesn't work is a technical argument. But wait: you get much degraded access to ftp.ie.debian.org over IPv6 than over IPv4. So you *do* have an v6-induced issue: degraded service to that particular host. No, I don't. You do, and again, it's not a v6-issue. It's a network that's not maintained properly. And even if the latency is high, the throughput is good, which means file transfer works fine and it's the main concern for an FTP server. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
On Sun, Apr 26, 2009 at 07:40:49PM +0100, Barak A. Pearlmutter wrote: ... Google is fully IPv6-enabled Sort of. I've used http://ipv6.google.com/. But Google has IPv6 disabled at the DNS level for www.google.com, albeit perhaps only for some requests. Watch: WRONG: $ host -t www.google.com www.google.com is an alias for www.l.google.com. www.l.google.com has IPv6 address 2001:4860:a004::68 They may do that based on geodns, but at least it is done for some subnet including mine. $ curl --ipv4 --silent --show-error http://www.google.com | wc -c 218 $ curl --ipv6 --silent --show-error http://www.google.com | wc -c curl: (6) Couldn't resolve host 'www.google.com' Why? Because enabling it would break or degrade performance on many IPv6-enabled clients, which would blithely prefer IPv6 and get sporadic service. If the clients defaulted to preferring IPv4, then this wouldn't be a problem, and Google could put IPv6 addresses into all DNS records, without risk. That's what I'd like to see happen. It won't until clients default to prefer IPv4. Your arguments do not work. Google *is* using IPv6, they consider IPv6 ready for the public. So Google is your IPv6 poster child? Watch! $ ping -c2 www.google.com PING www.l.google.com (216.239.59.104) 56(84) bytes of data. 64 bytes from gv-in-f104.google.com (216.239.59.104): icmp_seq=1 ttl=237 time=2.57 ms 64 bytes from gv-in-f104.google.com (216.239.59.104): icmp_seq=2 ttl=237 time=2.25 ms $ ping6 -c2 ipv6.google.com PING ipv6.google.com(fx-in-x68.google.com) 56 data bytes --- ipv6.google.com ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms $ timeout 60 telnet ipv6.google.com http Trying 2001:4860:a003::68... Timeout: aborting command ``telnet'' with signal 9 Killed $ ping -c2 www.google.com PING www.l.google.com (209.85.227.104) 56(84) bytes of data. 64 bytes from wy-in-f104.google.com (209.85.227.104): icmp_seq=1 ttl=246 time=10.3 ms 64 bytes from wy-in-f104.google.com (209.85.227.104): icmp_seq=2 ttl=246 time=10.3 ms --- www.l.google.com ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1003ms rtt min/avg/max/mdev = 10.352/10.375/10.399/0.104 ms $ ping6 -c2 www.google.com PING www.google.com(fx-in-x68.google.com) 56 data bytes 64 bytes from fx-in-x68.google.com: icmp_seq=1 ttl=59 time=12.3 ms 64 bytes from fx-in-x68.google.com: icmp_seq=2 ttl=59 time=12.0 ms --- ipv6.google.com ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1005ms rtt min/avg/max/mdev = 12.067/12.191/12.316/0.166 ms Looks like your should change your IPv6 provider. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
Given the problem you point out with this particular host, it's quite ironic, isn't it? What about getting them to fix it? ... Maybe it's because people complain on the BTS that IPv6 is preferred over IPv4 by default and this causes issues with ftp.ie.debian.org instead of telling the folks at Heanet about it? ... Or because people who should know better just shrug at it thinking it's just v6, v4 works, I'll got with that instead of looking at the issue and sending a quick mail to the people in charge? I'm sorry, but the people need to whine more solution does not scale. (What makes you think I have not reported these issues?) According to their own study, many IPv6-enabled clients is actually a minority. What is your point? No one is claiming a majority. The point is we should strive to not break ANYTHING. That is how transitions are encouraged: when you can honestly tell people that if they turn on IPv6 they will break *nothing*. That *no* clients will suffer. That *no one* will complain. Not that only a minority will have problems. $ ping -c2 www.google.com ... time=10.3 ms ... time=10.3 ms $ ping6 -c2 www.google.com ... time=12.3 ms ... time=12.0 ms Given the limited data you provide, it would appear that you would be better off using IPv4 for communicating with this particular host. You might say that someone who is not emotional about the situation, and cares only about network performance, would in this case prefer IPv4 over IPv6. Correct? --Barak. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
They may do that based on geodns, but at least it is done for some subnet including mine. Huh. Why do you suppose Google would do such an odd thing? --Barak. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
... It doesn't belong in APT, it should be a global, system-wide preference. I don't feel like adjusting the preferences of every single network program whenever I switch from a good IPv6 to a bad IPv6 network. I absolutely agree. Barak: if IPv6 is much slower than IPv4, please adjust the preferences in /etc/gai.conf. Just say precedence :::0:0/96 100 That configuration file is impossible for non-super-uber-expert programmers to find. $ man -k ipv6 | egrep gai | wc -l 0 $ man -k gai.conf gai.conf (5) - getaddrinfo(3) configuration file Preferring IPv4 over IPv6 should be the default. If there is any non-silly argument for not making it the default, I have not heard it. Please feel free to switch this bug over to Package: libc6, which holds /etc/gai.conf. Cheers, --Barak. -- Barak A. Pearlmutter Hamilton Institute Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
reassign 268631 libc6 retitle 268631 gai.conf difficult to find severity 268631 minor thanks Barak: if IPv6 is much slower than IPv4, please adjust the preferences in /etc/gai.conf. Just say precedence :::0:0/96 100 That configuration file is impossible for non-super-uber-expert programmers to find. $ man -k ipv6 | egrep gai | wc -l 0 $ man -k gai.conf gai.conf (5) - getaddrinfo(3) configuration file Preferring IPv4 over IPv6 should be the default. No. There are excellent reasons why IPv6 is preferred to IPv4 by default, and this is not going to change. Juliusz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
severity 268631 wishlist tag 268631 + wontfix thanks On Sat, Apr 25, 2009 at 11:59:16AM +0100, Barak A. Pearlmutter wrote: ... It doesn't belong in APT, it should be a global, system-wide preference. I don't feel like adjusting the preferences of every single network program whenever I switch from a good IPv6 to a bad IPv6 network. I absolutely agree. Barak: if IPv6 is much slower than IPv4, please adjust the preferences in /etc/gai.conf. Just say precedence :::0:0/96 100 That configuration file is impossible for non-super-uber-expert programmers to find. $ man -k ipv6 | egrep gai | wc -l 0 $ man -k gai.conf gai.conf (5) - getaddrinfo(3) configuration file Preferring IPv4 over IPv6 should be the default. If there is any non-silly argument for not making it the default, I have not heard it. IPv6 should be the default, that's the only way to do a transition to IPv6. Also it is mandated by a lot of RFC. They are plenty of other good reasons of preferring IPv6 over IPv4. It's not going to change. Tagging the bug as wontfix. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
There are excellent reasons why IPv6 is preferred to IPv4 by default, and this is not going to change. I'm very interested in this! What are the reasons? (The only serious argument I've heard boils down to: some IPv4 setups are broken by NAT and icky firewalls, and IPv6 isn't. One non-serious argument I've heard is: if IPv6 is not preferred then the v6 network will not get exercised.) Unfortunately the prefer IPv6 default has forced retraction (i.e., un-deployment) of IPv6 at a number of sites that I'm aware of. The story is simple: - enable IPv6: radvd, etc. - complaints that access to some IPv6-enabled host has become extremely slow or unreliable, across many local hosts. (E.g., updating from http://ftp.ie.debian.org) - cause is nonlocal IPv6 problems; cannot be locally addressed - infeasible to fiddle conf files on all potentially affected hosts - no choice: disable IPv6 If the default were to prefer IPv4, this would not happen. Enabling IPv6 would never cause such disruptions. This would make IPv6 deployment much easier. So, why do we insist upon default settings that make IPv6 deployment difficult? --Barak. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
On Sat, Apr 25, 2009 at 06:36:49PM +0100, Barak A. Pearlmutter wrote: (The only serious argument I've heard boils down to: some IPv4 setups are broken by NAT and icky firewalls, and IPv6 isn't. One non-serious argument I've heard is: if IPv6 is not preferred then the v6 network will not get exercised.) Yes, let's deploy IPv6, but also make sure that nobody use it! -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
Yes, let's deploy IPv6, but also make sure that nobody use it! If I understand what you're saying correctly, in essence, you feel sad inside when two IPv6-enabled hosts communicate using IPv4. That is not a technical argument. For the next few years at least, when both are available, IPv4 will typically be faster and more reliable than IPv6. That is the world we are living in. Imagine that you're Joe Network Admin. Which of the following two scenarios would make you more likely to deploy IPv6? (a) If you deploy IPv6 your users will (mainly in the future) be able to access more hosts, and have better connectivity. And *nothing* will break or slow down, so you won't get any complaints, only (mainly in the future) kudos. (b) If you deploy IPv6 your users will (mainly in the future) be able to access more hosts, and have better connectivity. However connectivity to some hosts may be dramatically degraded or disrupted, so you may get a bunch of immediate complaints, and addressing these will in all likelihood be impossible without un-deploying IPv6. It is up to us to choose whether option (a) or (b) holds, because these are controlled by client preference of IPv4 or IPv6 when both are available. Option (a) is clients prefer IPv4. Option (b) is clients prefer IPv6. If we go with option (a), we might actually be able to transition to IPv6 pretty soon. With option (b), the Internet will stay a ratty NATed IPv4 monster for much longer, possibly forever, because admins would have to be IPv6-loving masochists to enable IPv6, and most network admins just want their users to be happy and don't care about helping to hasten widespread deployment of IPv6, especially if doing so would make their users unhappy. Since I want to see IPv6 enjoy widespread deployment, I think option (a) would be a wise decision. --Barak. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#268631: force preference of IPv4 over IPv6
v4 is much faster on this route than v6. I suspect this is typical of IPv6-enabled machines, and will remain so for at least ten years. Please do not do that in APT. It doesn't belong in APT, it should be a global, system-wide preference. I don't feel like adjusting the preferences of every single network program whenever I switch from a good IPv6 to a bad IPv6 network. Barak: if IPv6 is much slower than IPv4, please adjust the preferences in /etc/gai.conf. Just say precedence :::0:0/96 100 Juliusz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
