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.