Am Montag, 22. Januar 2007 19:46 schrieb Thorsten Glaser: > Milan Holzäpfel dixit: > >> This hack > >> needs to be done in a .c file of the kernel and cannot be set at > >> runtime. > > > >Probably not a solution one would want to do :) > > Why not, if the other methods you described don't work?
I agree. If it would fix the problem, it would be the right thing to do. But it doesn't help, so forget about patching the kernel. I just wanted to explain what I already tried to understand why ipv6 doesn't work correct and how it might get fixed. It was part of my "understanding the problem" period :) > >I am not sure whether duplicate link-local addresses are a problem. If > >communication via eth0 isn't possible anyway (vlan setup) I think they > >should not do no harm. > > I don't think having one IP on two different (practical, not theoretical) > interfaces is something one should try. They may cause harm. You shouldn't do such things in real life, at least not with routable internet adresses. If you want to have an ip address that means the router/linux hosts directly and not just one particular interface, then bind these ip address on your loopback device (lo). In the linux world it's quite unusual to add ip adresses to your loopback device, but on cisco routers it's absolutly normal. The background is, that on cisco hosts the local ip address of an interface is not useable anymore, as soon as there is no link. On linux machines you can ping the local ip address of an interface, even if there is no link on that interface. Cisco admins are forced to add ip addresses to their loopback device, if they want to have an ip adress that is useable even without external connectivity. But for ipv6 link local adresses the thing is a bit more interessting anyway, and that because of the link local address refeclts the actual mac adress of the ethernet interface. If you have two interfaces with the same mac-address, then tey will have the same link-local adress for sure. But each link local address is meant to be a unique address in a collision domain (layer2 network) and is normally not allowed to be present more then once. Even if you have another private network with ipv6 running and maybe even official ipv6 ips on your interface. The network communication between your local hosts is always done basis of your link local adress. It (with some other thinks like ipv6-icmp) replaces the arp protocol completly. There is no arp in ipv6 at all. That's why link local is needed. > >By the way, does someone know whether we are able to disable generation > >of link-local addresses? In case we simply don't want to use them. > > That's not allowed by the standards, AFAIK, and there are > some reasons I don't remember off-hand. see above ;-) You can disable a complete interface for ipv6 if you like. Simply run "ip -6 addr flush <interface>" BTW: Some important information for all freewrt users that are interessted in ipv6. As I wrote the mails about the not fully functionable ipv6 implementation in freewrt I used the trunk version. In trunk the eth0 interface gets an link-local ipv6 adress as well as all official (annouced) ips and routes. That cannot be correct. But In "1.0.X" the thing doesn't look as bad. I tested this version some time later and realized that in 1.0 eth0 only gets a link local adress but the announced ips/networks are only added on eth0.0. The ipv6 connectivity is perfect. Even if I am not sure if eth0 should have the link local address at all. But as soon as you start to bridge interfaces it seems to be broken again. But this might not be freewrt related, because I guess this is just because a bridge is always started after all attached interfaces are already up (and might also have ipv6 addresses already). But this shoudl be easy to fix. The bridge helper for ifconfig should flush all ipv6 addresses from each bridge interface before the interface gets attached to the bridge. After that the bridge interface itself can bind the correct ip addresses. I am not sure how other distros handles this "problem". But I will test this later on... --Ralph _______________________________________________ freewrt-developers mailing list [email protected] https://www.freewrt.org/lists/listinfo/freewrt-developers
