Le lundi 2 avril 2007 18:39, vous avez écrit : > /etc/network/interfaces is not considered a configuration file and no > packages owns it. So you can modify it at will. I was referring to the backlist file, not interfaces. (...) > I think the overall price is worth the benefit. You won't think that way when Ubuntu gets dropped in favor of your-favorite-IPv6-capable-proprietary-OS-here at some big government agency, in some university campus, or by DVB-H users..., because for some reason IPv6 ended up on the overhyped requirements list (even if it won't be used in practice). But I'm getting off-topic > > On my system, the upgrade also had the very unkind effect of > > breaking ip6tables completely, since IPv6 autoloading got disabled, > > and any sane person will do firewall configuration before > > configuration the network interfaces. > I usually load a firewall on given protocol once lo is up on that > protocol for 2 reasons: I don't. Is it a reason to break my working system? Besides, it does not work either, since there were no need to set inet6 explicitly on lo so far. > 1) i can make sure the protocol is loaded ip6tables normally autoloads IPv6, which is the only sensical thing it could do. > 2) it is always executed before any real interface is up. That's a side effect. In practice, lo is created by the kernel, and the lo interface in /etc/network/interfaces is really a cosmetic entry. > Another way to hook up a firewall script to a specific protocol is to > use the /etc/modprobe.d/ to run a script as soon as a certain module > is loaded. If ipv6 gets loaded after some real interface is brought up, we get an unfirewalled time window, which was the precise reason for not doing it that way. > >> What MacOS does is also not completely proper. > > > > The MacOS X solution is far from perfect, but it is surely much > > less worse than permanently killing IPv6 because of a few broken > > DNS caches. > > s/caches/implementations and it's not just DNS here. As I said there > is also broken hardware around. It *is* only DNS, or pre-2.6.9 kernels with the default onlink assumption. Feisty has 2.6.20 plus glibc 2.5 with proper RFC3484 support. > It appears somebody is using it this way and it was brought up as use > case. I will check this up again. It appears many more people are using IPv6 and expect it to work out of the box on their Ubuntu Feisty, as it did in Dapper and Edgy. From reading the bug thread and the rants on freenode/#ipv6, I have a feeling I am not the only one. 18:44 remi@auguste ~% host basile.link basile.link has IPv6 address fe80::211:11ff:fe25:e6b4 18:44 remi@auguste ~% ssh basile.link ssh: connect to host basile.link port 22: Invalid argument 18:44 remi@auguste ~% ssh basile.link%eth0 ssh: basile.link%eth0: Name or service not known 18:44 remi@auguste ~% ping6 basile.link connect: Invalid argument 18:44 remi@auguste ~% ping6 basile.link -I eth0 -c 1 PING basile.link(basile.link) from fe80::20d:60ff:fe38:6d16 eth0: 56 data bytes 64 bytes from basile.link: icmp_seq=1 ttl=64 time=0.167 ms --- basile.link ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.167/0.167/0.167/0.000 ms ping6 is the only application that can handle this, which is of pretty limited use. Also, when you're down to doing link diagnostics, you probably cannot reach the DNS server, so you'd better use numerical addresses anyway. Also if both Apple and Microsoft does it that way on their IPv6-by-default general purpose OSes, it might not be such a stupid notion. > PS I don't exclude that the use case was based on personally > developed application that we cannot exclude to exist. So you would consider that an hypotetical personally-developed application, that breaks standard practices, and will only work on Linux, is more important than non-hypotetical people using IPv6 that are screwed by the last change? Wasn't it a "balance" thing? Regards, -- Rémi Denis-Courmont http://www.remlab.net/