In article <1087370535.24446.2981.camel@segesta.zurich.ibm.com> you wrote: >> If the application prefers ipv6 it will try to use them, and only on connect >> it receives an error. Some do then ipv4 fallback (lynx) some dont (mozilla). > > Fix your routing as that is the problem. No it is not, a Host with only link-local addresses is perfectly well configured. The application can actually bind to the family and try to connect to the internet destination, it will just have to deal with the net not reachable error. And some applications dont. (but this is actually only the reson why i ave looked at the sysctl options, even if all aplications are fixed the options still behave wrong) > Whenever a connect() fails > because there is no route or the connection is refused the getaddrinfo() > loop inside both those applications will try the next address, may that > be IPv4 or IPv6. Yes, obviously thats a good application behaviour, however its uncommon: # grep bla /etc/hosts 127.0.0.2 bla 127.0.0.3 bla ::2 bla ::3 bla # strace -e connect nc bla 1234 connect(3, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory) connect(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("127.0.0.2")}, 16) = -1 ECONNREFUSED (Connection refused) bla [127.0.0.2] 1234 (?) : Connection refused # strace -e connect nc6 bla 1234 connect(3, {sa_family=AF_INET6, sin6_port=htons(1234), inet_pton(AF_INET6, "::2", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address) connect(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("127.0.0.2")}, 16) = -1 EINPROGRESS (Operation now in progress) nc6: unable to connect to address bla, service 1234 # strace -e connect telnet bla 1234 Trying ::2... connect(3, {sa_family=AF_INET6, sin6_port=htons(1234), inet_pton(AF_INET6, "::2", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address) Trying 127.0.0.2... connect(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("127.0.0.2")}, 16) = -1 ECONNREFUSED (Connection refused) telnet: Unable to connect to remote host: Connection refused # strace -o /tmp/lynx -e connect lynx http://bla:1234 ; cat /tmp/lynx connect(3, {sa_family=AF_INET6, sin6_port=htons(1234), inet_pton(AF_INET6, "::2", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address) connect(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("127.0.0.2")}, 16) = -1 EINPROGRESS (Operation now in progress) connect(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("127.0.0.2")}, 16) = -1 ECONNREFUSED (Connection refused) # strace -ff -e connect mozilla-1.6 http://bla:1234 ... [pid 10224] connect(29, {sa_family=AF_INET6, sin6_port=htons(1234), inet_pton(AF_INET6, "::2", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address) Process 10228 detached ... None of the examples tried 4 conects. Iterating over all possible addresses within and across address families is not trivial, because it addes greatly to the timeout, it may generate unexpected additional connections and so it is application specific if and how to do it. Also interpreting some of the error codes (systematic, endpoint and address familiy specific) is not easy. Anyway, thats not the topic of this list here, my main question is about the wrong documentation of sysctl autoconf and the fact that there are two sysctl options which are doing the same. I am still convinced, that autoconf should eighter be removed or fixed, if you compare it with accept_ra. Anybody knows about the history of those options, more? > If you don't want IPv6 "rmmod ipv6", simple. That doesn fix the documentation bug and ambiquioty of the options. > An application can't protect itself from misconfigurations, or do you > want every application to do 'verifications' of the setup? :) No, but I want fast and efficient applications. And source address selection is a non trivial task for ipv6, as we all know (rfc3484). One of the issues is choosing scopes. For example, reaching a link-local web server is very complicated for an application which does not bind to a local address for interface selection purpose. > Like Trent mentions there: Fix the network ;) In this case the network is fine, the interface has only link local addresses, and the destination wqebsite is not reachable by them. > Protecting against userstupidity is not an option. Actually all the ipv6 transition documents are full of those protections. For example your link states: #It is bad practise to add an AAAA record for a node that does not #support all the services using IPv6 (rather, an AAAA record for the #specific service name and address should be used). However, the #application cannot depend on "good practise", and this must be #handled. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
