1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
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.
Partly because of these problems, the latest IPv6 API introduces an
explicit knob (the "IPV6_V6ONLY" socket option ) to turn off the ipv6
mapped address usage.
In bind9, we first check if both the advanced API and the IPV6_V6ONLY
socket option are available. If both of them are available, bind9
named will bind to the ipv6 wildcard port for both TCP and UDP.
Otherwise named will make a warning and try to bind to all available
ipv6 addresses separately.
In any case, bind9 named binds to specific addresses for ipv4 sockets.
The followings are historical notes when we always bound to the ipv6
wildcard port regardless of the availability of the API support.
These problems should not happen with the closer checks above.
IPV6 Sockets Accept IPV4, Specific IPV4 Addresses Bindings Fail
---------------------------------------------------------------
The only OS which seems to do this is (some kernel versions of) 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
-------------
3513: Internet Protocol Version 6 (IPv6) Addressing Architecture
3493: Basic Socket Interface Extensions for IPv6
3542: Advanced Sockets Application Program Interface (API) for IPv6
|
