1194N/ACurrently, there are multiple interesting problems with ipv6
1194N/Aimplementations on various platforms. These problems range from not
1194N/Abeing able to use ipv6 with bind9 (or in particular the ISC socket
1194N/Alibrary, contained in libisc) to listen-on lists not being respected,
1194N/Ato strange warnings but seemingly correct behavior of named.
1194N/AThe socket library requires a certain level of support from the
1194N/Aoperating system. In particular, it must follow the advanced ipv6
1194N/Asocket API to be usable. The systems which do not follow this will
1194N/Acurrently not get any warnings or errors, but ipv6 will simply not
1194N/AThese systems currently include, but are not limited to:
1194N/A AIX 3.4 (with ipv6 patches)
1194N/AIn the original drafts of the ipv6 RFC documents, binding an ipv6
1194N/Asocket to the ipv6 wildcard address would also cause the socket to
1194N/Aaccept ipv4 connections and datagrams. When an ipv4 packet is
1194N/Areceived on these systems, it is mapped into an ipv6 address. For
1194N/Aexample, 1.2.3.4 would be mapped into ffff::1.2.3.4. The intent of
1194N/Athis mapping was to make transition from an ipv4-only application into
1194N/Aipv6 easier, by only requiring one socket to be open on a given port.
1194N/ALater, it was discovered that this was generally a bad idea. For one,
1194N/Amany firewalls will block connection to 1.2.3.4, but will let through
1194N/Affff::1.2.3.4. This, of course, is bad. Also, access control lists
1194N/Awritten to accept only ipv4 addresses were suddenly ignored unless
1194N/Athey were rewritten to handle the ipv6 mapped addresses as well.
1194N/AIn bind9, we always bind to the ipv6 wildcard port for both TCP and
1194N/AUDP, and specific addresses for ipv4 sockets. This causes some
1194N/Ainteresting behavior depending on the system implementation of ipv6.
1194N/AIPV6 Sockets Accept IPV4, Specific IPV4 Addresses Bindings Fail
1194N/A---------------------------------------------------------------
1194N/AThe only OS which seems to do this is linux. If an ipv6 socket is
1194N/Abound to the ipv6 wildcard socket, and a specific ipv4 socket is
1194N/Alater bound (say, to 1.2.3.4 port 53) the ipv4 binding will fail.
1194N/AWhat this means to bind9 is that the application will log warnings
1194N/Aabout being unable to bind to a socket because the address is already
1194N/Ain use. Since the ipv6 socket will accept ipv4 packets and map them,
1194N/Ahowever, the ipv4 addresses continue to function.
1194N/AThe effect is that the config file listen-on directive will not be
1194N/AIPV6 Sockets Accept IPV4, Specific IPV4 Address Bindings Succeed
1194N/A----------------------------------------------------------------
1194N/AIn this case, the system allows opening an ipv6 wildcard address
1194N/Asocket and then binding to a more specific ipv4 address later. An
1194N/Aexample of this type of system is Digital Unix with ipv6 patches
1194N/AWhat this means to bind9 is that the application will respect
1194N/Alisten-on in regards to ipv4 sockets, but it will use mapped ipv6
1194N/Aaddresses for any that do not match the listen-on list. This, in
1194N/Aeffect, makes listen-on useless for these machines as well.
1194N/AIPV6 Sockets Do Not Accept IPV4
1194N/A-------------------------------
1194N/AOn these systems, opening an IPV6 socket does not implicitly open any
1194N/Aipv4 sockets. An example of these systems are NetBSD-current with the
1194N/Alatest KAME patch, and other systems which use the latest KAME patches
1194N/Aas their ipv6 implementation.
1194N/AOn these systems, listen-on is fully functional, as the ipv6 socket
1194N/Aonly accepts ipv6 packets, and the ipv4 sockets will handle the ipv4
2373: IP Version 6 Addressing Architecture
2553: Basic Socket Interface Extensions for IPv6
draft-ietf-ipngwg-rfc2292bis-01: Advanced Sockets API for IPv6 (draft)
$Id: ipv6,v 1.2 2000/05/23 22:42:00 gson Exp $