Hello, I started that discussion on linux-kernel, but I think it is better here: The problem is, that it is not possible to up an ipv4 interface completely without an ipv6 address (as long as the kernel is ipv6 enabled) The ip-sysctl help tells me that it should be possible to use "autoconf" to avoid the link local (and loopback?) address, and accept_ra to avoid stateless autoconfigured router prefix announcements: # accept_ra - BOOLEAN # Accept Router Advertisements; autoconfigure using them. # # Functional default: enabled if local forwarding is disabled. # disabled if local forwarding is enabled. ... # autoconf - BOOLEAN # Configure link-local addresses using L2 hardware addresses. # # Default: TRUE However this is not correct, autoconf does only affect the same addresses as accept_ra does, i.e. the one announces (global and site local). So I think autoconf=0 should avoid adding the fe80:: link local address (as well as lo ::1), as documented. There are application problems, if the interface has (only) the link local prefix or corrupt global prefixes. 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). So qestions: - is the kernel interpretation auf autoconf=0 or the documntation right? - how should an application avoid connecting via an interface which has only addresses for the wrong scope? - is falling back from v6 to v4 on connect errors somehwere recommended/described? I can prepare a kernel patch to make autoconf stop configuring any ipv6 address on upping an interface. Some of the discussion is archived on the debian bugtracker: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=253590 Greetings Bernd -- (OO) -- Bernd_Eckenfels@Mörscher_Strasse_8.76185Karlsruhe.de -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E eckes@IRCNet v:+497211603874 f:+497211606754 (O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! - : 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
