Copyright (C) 2000, 2001 Internet Software Consortium. See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. Currently, there are multiple interesting problems with ipv6 implementations on various platforms. These problems range from not being able to use ipv6 with bind9 (or in particular the ISC socket library, contained in libisc) to listen-on lists not being respected, to strange warnings but seemingly correct behavior of named. COMPILE-TIME ISSUES ------------------- The socket library requires a certain level of support from the operating system. In particular, it must follow the advanced ipv6 socket API to be usable. The systems which do not follow this will currently not get any warnings or errors, but ipv6 will simply not function on them. These systems currently include, but are not limited to: AIX 3.4 (with ipv6 patches) RUN-TIME ISSUES --------------- In the original drafts of the ipv6 RFC documents, binding an ipv6 socket to the ipv6 wildcard address would also cause the socket to accept ipv4 connections and datagrams. When an ipv4 packet is received on these systems, it is mapped into an ipv6 address. For example, 1.2.3.4 would be mapped into ffff::1.2.3.4. The intent of this mapping was to make transition from an ipv4-only application into ipv6 easier, by only requiring one socket to be open on a given port. Later, it was discovered that this was generally a bad idea. For one, many firewalls will block connection to 1.2.3.4, but will let through ffff::1.2.3.4. This, of course, is bad. Also, access control lists written to accept only ipv4 addresses were suddenly ignored unless they were rewritten to handle the ipv6 mapped addresses as well. In bind9, we always bind to the ipv6 wildcard port for both TCP and UDP, and specific addresses for ipv4 sockets. This causes some interesting behavior depending on the system implementation of ipv6. IPV6 Sockets Accept IPV4, Specific IPV4 Addresses Bindings Fail --------------------------------------------------------------- The only OS which seems to do this is linux. If an ipv6 socket is bound to the ipv6 wildcard socket, and a specific ipv4 socket is later bound (say, to 1.2.3.4 port 53) the ipv4 binding will fail. What this means to bind9 is that the application will log warnings about being unable to bind to a socket because the address is already in use. Since the ipv6 socket will accept ipv4 packets and map them, however, the ipv4 addresses continue to function. The effect is that the config file listen-on directive will not be respected on these systems. IPV6 Sockets Accept IPV4, Specific IPV4 Address Bindings Succeed ---------------------------------------------------------------- In this case, the system allows opening an ipv6 wildcard address socket and then binding to a more specific ipv4 address later. An example of this type of system is Digital Unix with ipv6 patches applied. What this means to bind9 is that the application will respect listen-on in regards to ipv4 sockets, but it will use mapped ipv6 addresses for any that do not match the listen-on list. This, in effect, makes listen-on useless for these machines as well. IPV6 Sockets Do Not Accept IPV4 ------------------------------- On these systems, opening an IPV6 socket does not implicitly open any ipv4 sockets. An example of these systems are NetBSD-current with the latest KAME patch, and other systems which use the latest KAME patches as their ipv6 implementation. On these systems, listen-on is fully functional, as the ipv6 socket only accepts ipv6 packets, and the ipv4 sockets will handle the ipv4 packets. RELEVANT RFCs ------------- 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.1.1.1 2003/01/10 00:48:09 bbraun Exp $