ipv6 routes messed up after installing aiccu (sixxs)

Installed aiccu on a fresh raspbian from the raspberrypi.org website.
Logged in with sixxs tunnel with subnet attached.

Suddenly the computers in my local network (has only ipv4 from provider) get ipv6 addresses, but can only connect inside the ipv6 subnet, not globally.

On the rpi I then find that eth0 has also gotten assigned an ipv6 address from the sixxs-subnet and that this is set as the default route for ipv6 packets. Because of this, ipv6 packets get never routed over the tunnel.

ip -f inet6 routes show outputs:
::/96 dev sit0 metric 256
2001:4dd0:ff00:0xxx::/64 dev sixxs proto kernel metric 256
2001:4dd0:ff00:8xxx::/64 dev eth0 proto kernel metric 256 expires 86390sec
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev sixxs proto kernel metric 256
default via fe80::226:22ff:fe14:d168 dev eth0 proto ra metric 1024 expires 80sec

The 'aiccu test' command gives the following insight: i can ping and traceroute the tunnel endpoint, but packets to other global hosts do not get routed through it.

Adding 'default via 2001:4dd0:ff00:0xxx::1 dev sixxs proto kernel metric 256' and deleting the other default makes me able to connect globally over ipv6 again, but after a short time the lease (?) gets renewed and the old default is back again.

This is very annoying since it renders sixxs useless.

I initially discovered this bug on my old raspbian install. It occured after the last update of aiccu. With it also came the new interface sit0. I thought that the bug may be due to usual os breakdown over time and because of that reinstalled raspbian from a newly downloaded image. Now i find (as discribed above) that the bug ist still there.

Do you need any additional information from me?

This is my first bug report, so sorry for any mistakes in advance.
I filed the bug here and not on the debian bug system because I thought it may be something rpi related. Was that right?

Greetings,

Lukas

[P33M]

This repository is for the Raspberry-Pi specific Linux kernel and only kernel-related issues should be reported here.

This smells like a userspace program bug - if you can replicate it on a straight Debian Wheezy OS (on a PC) then post your report on the Debian bug tracker, otherwise post on the Raspbian bug tracker.

Hello,

I figured that out too after reading some closed issues here.

Before I read your answer I already opened a bug on the raspbian bug system because of here being only kernel development. (https://bugs.launchpad.net/raspbian/+bug/1267446)

Should I just close the report here?

As a sidenote: I came here reporting the bug because of the Raspbian bug page (http://raspbian.org/RaspbianBugs). There is this text about checking wether the bug has been reported here or on the debian bug system already, which is obviously a good advice, but I also read it like „you are supposed to report there first“ and neither the Raspbian bug page or this issue page here state that this place is for kernel bugs only - of cause it again is obvious if you read a little here, but for me as a beginner, it wasn't on the first glimpse. Maybe you could somehow clarify this to avoid nuisance (like me) here ;)

Above all: thank you for developing on the RPi. I really appreciate using it!

Greetings,

Lukas

[popcornmix]

If the bug is present in this linux kernel source tree then report it here.
If the bug is present in a raspbian package, then report it to RaspbianBugs.

Sometimes it may not be obvious. If it occurs on a fresh installation, if it's related to attaching hardware, if there are errors in dmesg log, then its probably a linux kernel issue.

If it occurs after (apt-get) installing or updating a package then it's probably a raspbian issue.

I'll close this as it doesn't sound like a kernel issue to me.

[massar]

default via fe80::226:22ff:fe14:d168 dev eth0 proto ra metric 1024 expires 80sec

Note the "proto ra", that indicates that ANOTHER host is using IPv6 Router Advertisement (RA) to announce a prefix on that link. The host doing that is fe80::226:22ff:fe14:d168 aka the one with the 00:26:22:14:d1:68 MAC address. SSH to it or check 'ip nei show' to figure out the IPv4 address of that host.

Hence, it is not a kernel bug, it is not a bug relating to SixXS or AICCU either; it is just a configuration issue.

To fix either:

1. figure out which host is announcing it and disable those announcements
2. Disable accepting RA on that host you don't want them accepted on:
   sysctl -w net.ipv6.conf.all.accept_ra=0
   sysctl -w net.ipv6.conf.default.accept_ra=0
   sysctl -w net.ipv6.conf.eth0.accept_ra=0
   or stuff similar things in /etc/sysctl.conf(.d/xxx)