From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 Description of problem: Local IPv6 address is always assigned to network interface (at least for eth, not sure for others), even if I have NETWORKING_IPV6 set to no (or interface specific IPV6INIT set to no). sit0 device is also always present, althoug by looking into ifup-sit script it shouldn't be if NETWORKING_IPV6 is set to no. Strange. It wouldn't be much of the issue, however, I have an ethernet interface for which I do not want any IP (or IPv6) address to be assigned (it's the interface connected to ADSL modem). It would be nice to be able to disable things I do not need (like IPv6 local addresses and sit0 stuff). Version-Release number of selected component (if applicable): initscripts-7.42-1 How reproducible: Always Steps to Reproduce: 1. set NETWORKING_IPV6 in networking and/or IPV6INIT in interface specific files to no 2. /etc/init.d/networking restart 3. /sbin/ifconfig -a Actual Results: Interfaces have IPv6 address assigned, sit0 interface is there (althoug not in UP state) Expected Results: Shouldn't have any IPv6 on network interfaces. There shouldn't be sit0 sitting there. Additional info:
Are you using a 2.6 kernel?
Yes. I'm using kernel-2.6.0-0.test11.1.13 (just playing around with IPsec, so if anybody needs feedback for ifup-ipsec, what I like, don't like, problems, and stuff)...
This behavior starts with the 2.6 kernel, that's why I asked. Will have to check where it's coming from.
This is also occuring in FC2 test3 with all updates applied as on May 06th. This doesn't occur on Fedora Core 1 with a 2.6 kernel downloaded from kernel.org
Are both kernels configured the same?
I just run into problems with BIND because of this. BIND will try to use IPv6 whenever it encounters sites with NS records pointing to IPv6 addresses. Which is bad. Depending on which ISP is used and on firewall configuration this can lead to failed queries and all other sorts of problems. From what I can see (now using Fedora Core 2, both original 2.6.5 kernel and latest 2.6.8.1 kernel), IPv6 address assigned to the Ethernet interface is based on the Ethernet card MAC address as follows: - fe80::2 - 2nd byte of MAC address - 3rd byte of MAC address - ff:fe - 4th byte of MAC address - 5th byte of MAC address - 6th byte of MAC address So, if MAC address is 11:22:33:44:55:66, interface will be assigned this address: fe80::222:33ff:fe44:5566/64 scope link. I have no idea where and how this is generated (I've looked through scripts in networking-scripts, but found nothing). Loopback interface gets standard ::1/128 Scope:Host. I'm not sure how ppp interfaces (or any other type of interface apart from Ethernet and loopback) are handled. This migh be a security risk too. Many cable ISPs today will assign name to client based on the MAC address of client's external interface (the one cable modem is connected to). They will also have this name automatically updated in DNS. I know couple of big cable operators in US and Canada that are doing this (I'm using one of them). By simply doing reverse DNS lookup of such client IPv4 address you get client's MAC address (you'll get something like xyz112233445566.cable-operator.net, where 112233445566 is client's MAC address). From this MAC address, you get IPv6 address (see above). ip6tables are not installed by default, and they are not configured by firewall configuration scripts. Client is protected in IPv4 address space, but completely open in IPv6 address space. If attacker can manage to get routing to the client's IPv6 address somehow (hm, maybe if he is on same cable segment as victim, or if Fedora box is wireless access point) he will bypass the firewall. Also, some sites will also use firewall rules on loopback interface (if somebody gets into the machine as regular user, it still doesn't mean he should be allowed to connect to any service using loopback interface). This behaviour opens up firewall behind administrators back for loopback interface. A simple workaround for security issue is to install ip6tables, and put something like this in /etc/sysconfig/ip6tables: *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] COMMIT [however, if you have BIND running on the host, this might lead to problems with resolving, since BIND will try to use IPv6 for some domains. you'll get resolving failures until BIND tiemouts IPv6 request, and fails back to IPv4. other applications might suffer too.] A bit more complex workaround would be writing script that removes these IPv6 addresses from all interfaces during boot (and to modify /etc/init.d/network to call it). Interestingly, if I bring the interface up using ifconfig from command line no IPv6 address is assigned to it. I haven't tested extensivly ip command, but it doesn't seem that it is doing this automatic autogeneration of IPv6 address either (not 100% sure, maybe that one is culprit after all). All in all, I must say to whomever implemented this automatic asssignment of IPv6 address that it was *very* bad idea. Nobody has use for it. If somebody is using IPv6, he/she will assign specific address to interface manually (or using DHCP) anyhow. For average Joe this is of no use at all. And might even present severe security risk.
Scrap the part of comment about ifconfig command. I mixed up something. Even when called from command line, ifconfig/ip will add autogenerated IPv6 address.
Third consecutive comment today. Oh well. I did some additional research. I found this web page from Microsoft that explains exactly how link local IPv6 address is derived: http://www.microsoft.com/technet/prodtechnol/winxppro/plan/faqipv6.mspx [click on "How is the linkâlocal address derived?"] Linux kernel is basically doing exactly the same thing. Furthermore, the IPv6 that is assigned to the interface is assigned by kernel ipv6 module. On 2.4 kernel, if you do "insmod ipv6" and than "ifconfig", you'll see this link-local address assigned to the interface. For some reason, ipv6 module is always loaded in Fedora Core (1 and 2) when 2.6 kernel is used. When 2.4 kernel is used (in Fedora Core 1) it is not automatically loaded. Once ipv6 module is loaded, you can't just unload it (it gets automatically used). So I guess, we'd need to find what triggers automatic loading of ipv6 kernel module (even when it is not needed/wanted). And why this happens when 2.6 kernel is used, but not when 2.4 kernel is used (compilation defaults in kernel configuration?).
After doing much more googling around for ipv6 related docs. (wish I did it long before I initially opened this bug report, parts of my previous comments now look kind of silly to me ;-)... I don't know if and how potential attacker could use link local IPv6 address (if defined on interface, and it seems to be defined for all Fedora Core 2 installations). I've tried to connect from one host to another host (on the same LAN) using this link local address, but it failed (with invalid argument). On the other hand, if I add global ipv6 address to second host, I can connect from the first host (first host will use this link local address as source address). The question is, if attacker runs modified kernel on host A, can it connect to host B (on the same LAN) using only (autoconfigured) link local addresses? If the answer is yes, than he should be able to use this to attack internal network after he gains control over one or more hosts in DMZ (provided network admins haven't configured IPv6 firewall, since they use "only" IPv4). Regardles of that, there's still a problem with all this. If user installs Fedora Core 2, and configures iptables only with IPv4 in mind, and wish to limit connectivity on loopback interface, there is still a hole because IPv6 would be unrestricted. For example, attacker gets into the DMZ system but gains only "regular user" priviledges. There's vaulnerable service (for example unpatched ssh), but firewall rules are blocking access to it from WAN and loopback (only accessible from LAN). Attacker can use IPv6 to bypass firewall rules and attack this service to gain root priviledges. This is a big change and many users might not be aware of it (that they need to install ip6tables, and configure them separately from iptables). Also, if user limits outgoing packets on IPv4 only host A (for example firewall, or DMZ host), and there is IPv6 host B on local LAN, he again all the sudden got a gaping hole in firewall configuration that hasn't existed before he switched to 2.6 kernel (well, he used to have clean IPv4 host before, so firewall was configured only for IPv4). Anyhow, even if we dismiss all of this security-related mumbo-jumbo, the original problem is still here. How to get clean IPv4 (as in clean from IPv6) Fedora host running 2.6 kernel. Other than removing ipv6 module from disk.
I've did some tests yesterday and last night. Loading of ipv6 module (and hence autoconfigured IPv6 addresses assigned to interfaces) doesn't seem to have anything to do with init scripts in /etc/init.d directory. If I rename ipv6.ko to something else, than reboot machine, and after the boot is complete rename the module to its original ipv6.ko name, it gets mysteriously loaded after some time (just sit and wait, and after some time something somehow loads it). It seems that 2.6 kernel is more trigger happy to autoload modules than 2.4 kernel. Either some process (or more of them) are using something undocumented to probe for IPv6 that worked on 2.4 kernel (but is causing ipv6 module to autoload on 2.6 kernel). Or there's a bug in 2.6 kernel that loads that module even when it really shouldn't. It seems that ipv6 is automatically loaded even when only core and base packages are installed on the machine and when there are almost no services running on it. Strange. Is there any debugging tool that could show wich process (and during which system call) triggered autoloading of kernel module? Without something like that, it might be quite tedious job to single out what and why is triggering loading of ipv6 module in 2.6 kernel. Is there an configuration file (modprobe.conf? what syntax?) to instruct kernel never to autoload a particular module (but leave autoloading on for other modules)?
Last comment in this monolouge series. Promise. I've accidentaly found a way to kind of debug what loads ipv6 module. I attempted to put this line in /etc/modprobe.conf: options ipv6 autoconf=no (just trying to guess if there's such option). There is no autoconf option in ipv6 module, so basically it will fail to load every time when it is invoked. After depmod -a and rebooting, there was message that ipv6 module failed to load after each and every IPv6 aware daemon was started. Having everything else the same (except the kernel), it seems that it has to have something with changes in 2.6 kernel. 2.4 kernel obviously doesn't autoload ipv6 when service attempts to bind to all interfaces using both IPv4 and IPv6. 2.6 kernel automatically loads the module. Furthermore, even after daemons are started and binded to ports they will listen to, 2.6 kernel will autoload ipv6 module as soon as it can. I've played around with sshd (since for that one binding to IPv6 can be terned on and off). In default configuration, starting sshd it will trigger loading of ipv6 module. If line "Listen 0.0.0.0" is added, starting sshd will not trigger loading of ipv6 module. So, should this bug report be reassigned to kernel component?
I have been going down the same wormhole with ipv6. My eth0 connects to a router to an adsl modem then to SBC ISP. Short of deleting the ipv6.ko module, ipv6 ALWAYS eventually gets loaded, and jams up my router / adsl modem. The ONLY way I have found to get out of this lockup is to power down computer / router / modem and start fresh. X also triggers the loading of ipv6.ko - which was a surprising piece of the puzzle to me. Aliasing ipv6 off (or true) seemed to intercept module loading temporarily, but inevitably ipv6.ko gets loaded and the entire connection comes crashing down. Surprisingly, having a windows machine also on the router APPEARS to stabilize the connection. Shuttign the windows machine off, . . . . a few hours later, down goes the connection. I tried discovering if SBC is maybe doing something funky regarding ipv6 - as in supporting SOME ipv6 protocols but not others - that was triggering the ipv6 address negotiation; but could not find out anything. Possibly related issues: - I have noticed possible interactions among ipv6 / network card / sound card / video cards. Video: ATI AIW Radeon 9000 AGP - radeon.ko / radeonfb.ko Sound: Onboard - snd-intel8x0.ko Creative SoundBlaster - snd-ens1371.ko Network: Onboard - 8139too.ko D-Link 503 - 8139too.ko - It SEEMS turning on sound intermittently triggers a series of network blips, overall system pauses (30 seconds). - I wind up reconfiguring sound / network just to get them re-detected. I (as an experiment) threw a new hard drive in and installed Win98 and the device drivers to see what it came up with. MANY more devices were detected and configured for the sound, and video - and . . . . the VIDEO DRIVER WAS SHOWING AN ADDITIONAL NETWORK CONNECTION! Is ATI relying on IPv6 networking to drive the video card? Similarly, the audio card had a network connection driver from windows. As usual under windows, the TV portion of the Video card worked for a while, then gave up the ghost. But, it is more than has ever worked under Linux. IPv6 seems to be the glue among these issues - Any ideas?
I guess 2.6 kernel or related modutils (not sure, I haven't checked, but at least modutils included it at some point) includes internal net-pf-10 mapping to the IPv6 module, and it isn't possible to override calling that from the userspace in /etc/modules.conf ? If so, the root issue would probably be beyond the scope of initscripts package ?
Yup. The culprit in this case seems to be kernel. I've posted this question on kernel bug tracking list, and got answer that, if I don't want IPv6, I should disable compiling IPv6 support. I had two issues with this answer. First, I'm loosing the benefits of packaged system. Also, upgrading the kernel would take couple of hours (with recompiling), instead couple of minutes (just adding new kernel packages). Second, what if my only Linux box is firewall with bare minimum of packages (bare minimum definetely does not include compiler). Than I'll be unable to recompile kernel, even if I wanted to do so. Anyhow, since obviously kernel developers have that fetish that everybody should compile kernel (and ditch the precompiled packages), somehow I doubt this will ever be addressed.
Re: #13 From Pekka Savola (pekkas) Pekka, you were on the right track :-) Adding this line to modprobe.conf disables IPv6 on machine: alias net-pf-10 off The only open question now is, should this be added by default if user specifies that he does not need/want IPv6 during installation?
I guess it could be possible to add that to /etc/modules.conf at initscripts if someone specifies NETWORKING_IPV6=no (not just leaving it empty), but that has at least two corner cases to deal with, like: a) ensure that it won't get added multiple times b) remove the line if NETWORKING_IPV6 is no longer set to no
After discussing it for a long time on several places, including LKML, Linux bugzilla, and some mailing lists, seems that most people don't object having IPv6 always on. Kernel developers seem to want this kind of behaviour whenever ipv6 module is included with kernel. Oh well, let admit I'm minority and go with the main stream.