Comment 59 for bug 24828

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/