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