reassign 560238 tech-ctte
thanks
Dear members of the Technical Committee,
There has been an extensive discussion about the proper default value of the
net.ipv6.bindv6only sysctl, both on the debian-devel mailing list and in
bugreport 560238. Since people are clearly divided on the issue, and it is
unlikely a compromise can be found, I have forwarded it to you for a decision.
Please read the past discussion, but to summarise the arguments for both
possible default values:
net.ipv6.bindv6only = 0
-----------------------
* This is the default value of the Linux kernel.
* This value is used as a default in many other Linux distributions.
* This behaviour is the opposite of the default of the FreeBSD kernel.
* Many applications work properly (ie, support both IPv4 and IPv6
simultaneously) only with this setting.
* The behaviour of the network stack with this value conforms to RFC 3493
sections 3.7 and 5.3.
* It is said to conform to POSIX 2008, Volume 2, Section 2.10.20.
* Instead of IPv4 addresses, sockets return IPv6-mapped addresses, and not all
software handles this properly (ie, and ACL for an IPv4 address gets ignored
because the software only sees an IPv6 address).
* This value does not introduce new bugs.
* Setting this value now will keep unstable in a more usable state.
net.ipv6.bindv6only = 1
-----------------------
* This restricts IPv6 addresses to IPv6 sockets, and IPv4 address to IPv4
sockets, making interpretation of addresses unambiguous, and hence increases
security of programs.
* This requires some applications to be adapted to support multiple sockets.
* The behaviour of the network stack with this value is the same as the default
behaviour of FreeBSD.
* This value reduces security bugs, but introduces new bugs since some
applications no longer work as expected.
* This value will flush out all applications that cannot handle an alternative
setting of net.ipv6.bindv6only.
* Setting this value now will get more bugs fixed before the next release.
In the past maintainers have pushed for new ways for doing things that upset
the status quo. The idea is that introducing new functionality, although it
will break some existing functionality, will result in faster convergence to a
better situation. Opponents will argue that new functionality should
preferrably only be introduced when it will not break exisiting functionality.
I hope the Committee will issue a statement whether the former is, in general,
accepted behaviour, or if Debian should be more conservative.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@debian.org>
Attachment:
signature.asc
Description: Digital signature