summaryrefslogtreecommitdiff
path: root/doc/ipv6.html
blob: 67c8e1fc13636a2d03378d860e9094cc18b420f7 (plain)
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
<html>
<head>
<title>Notes on IPv6 Handling in Rsyslog</title>
</head>
<body>
<h1>Notes on IPv6 Handling in Rsyslog</h1>
<p><b>Rsyslog fully* supports sending and receiving syslog messages via both 
IPv4 and IPv6.</b> IPv6 is natively supported for both UDP and TCP. However, 
there are some options that control handling of IPv6 operations. I thought it is 
is a good idea to elaborate a little about them, so that you can probably find 
your way somewhat easier.</p>
<p>First of all, you can restrict rsyslog to using IPv4 or IPv6 addresses only 
by specifying the -4 or -6 command line option (now guess which one does 
what...). If you do not provide any command line option, rsyslog uses IPv4 and 
IPv6 addresses concurrently. In practice, that means the listener binds to both 
addresses (provided they are configured). When sending syslog messages, rsyslog 
uses IPv4 addresses when the receiver can be reached via IPv4 and IPv6 addresses 
if it can be reached via IPv6. If it can be reached on either IPv4 and v6, 
rsyslog leaves the choice to the socket layer. The important point to know is 
that it uses whatever connectivity is available to reach the destination.</p>
<p><b>There is one subtle difference between UDP and TCP.</b> With the new 
IPv4/v6 ignorant code, rsyslog has potentially different ways to reach 
destinations. The socket layer returns all of these paths in a sorted array. 
For TCP, rsyslog loops through this array until a successful TCP connect can be 
made. If that happens, the other addresses are ignored and messages are sent via 
the successfully-connected socket.</p>
<p>For UDP, there is no such definite success indicator. Sure, the socket layer 
may detect some errors, but it may not notice other errors (due to the 
unreliable nature of UDP). By default, the UDP sender also tries one entry after 
the other in the sorted array of destination addresses. When a send fails, the 
next address is tried. When the send function finally succeeds, rsyslogd assumes 
the UDP packet has reached its final destination. However, if rsyslogd is 
started with the &quot;-A&quot; (capital A!) was given on the command line, rsyslogd will 
continue to send messages until the end of the destination address array is 
reached. This may result in duplicate messages, but it also provides some 
additional reliability in case a message could not be received. You need to be 
sure about the implications before applying this option. In general, it is NOT 
recommended to use the -A option.</p>
<p><i><b>*</b>rsyslog does not support RFC 3195 over IPv6. The reason is that 
the RFC 3195 library, <a href="http://www.liblogging.org/">liblogging</a>, 
supports IPv4, only. Currently, there are no plans to update either rsyslog to 
another RFC 3195 stack or update liblogging. There is simply no demand for 3195 
solutions.</i></p>
<p><font size="2">Last Updated: 2007-07-02<br>
Copyright &copy; 2007 by Rainer Gerhards, released under the GNU GPL V2 or later.</font></p>

</body>
</html>