Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")

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.6 2004/03/05 05:04:53 marka Exp $