ipv6

bind-3.2.

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.5 2001/01/09 21:50:27 bwelling Exp $