File: tayga.conf.5

package info (click to toggle)
tayga 0.9.2-8
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 668 kB
  • sloc: ansic: 5,546; sh: 1,176; makefile: 23
file content (195 lines) | stat: -rw-r--r-- 6,428 bytes parent folder | download
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
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
.TH TAYGA.CONF "5" "Dec 2018" "TAYGA 0.9.2" ""
.SH NAME
tayga.conf \- configuration file of the TAYGA stateless NAT64 daemon
.SH DESCRIPTION
This file contains the configuration parameters for the TAYGA stateless NAT64
daemon.  It must exist and contain the mandatory configuration items or
TAYGA will refuse to run.
.P
The configuration directives are listed below.  With the exception of the
.B map
directive, only one instance of each directive may appear in tayga.conf.
.TP
.BI "tun-device " device
Name of the network interface that will be created by the kernel TUN module
for TAYGA to exchange IPv4 and IPv6 packets with the in-kernel TCP/IP stack.
If
.I device
does not already exist as a persistent interface (created by the
.B \-\-mktun
flag to tayga(8), for example), it will be created automatically when the
TAYGA daemon starts and destroyed when the daemon exits.
.IP
Note that TAYGA does not configure the host-side parameters of
.I device.
This must be done by the system administrator using the ifconfig(8), route(8),
and/or ip(8) commands.
.IP
This configuration directive is mandatory.
.TP
.BI "ipv4-addr " ipv4_address
IPv4 address that TAYGA will use as the source address for ICMPv4 errors
generated by the translation process.  TAYGA will also respond to ICMP echo
requests (pings) at this address.
.IP
.I ipv4_address
is permitted to overlap with the prefix specified in the
.B dynamic-pool
directive, in which case
.I ipv4_address
will be removed from the pool of available addresses.
.IP
This configuration directive is mandatory.
.TP
.BI "ipv6-addr " ipv6_address
IPv6 address that TAYGA will use as the source address for ICMPv6 errors
generated by the translation process.  TAYGA will also respond to ICMPv6 echo
requests (pings) at this address.
.IP
This configuration directive is mandatory unless the NAT64 prefix is specified
with the
.B prefix
directive, in which case TAYGA will generate its IPv6 address by mapping the
address specified in
.B ipv4-addr
into the NAT64 prefix.
.TP
.BI "prefix " ipv6_address/length
NAT64 prefix for mapping IPv4 addresses into the IPv6 address space.  TAYGA
performs address translation as specified in RFC 6052, and only prefix lengths
allowed in that document will be permitted in the
.B prefix
directive.
.IP
The use of either a Network-Specific Prefix or the Well-Known Prefix
(64:ff9b::/96) is allowed,
.B however,
as required by RFC 6052, TAYGA will refuse to translate packets with a
source or destination address composed of the Well-Known Prefix and a
non-global IPv4 address (10.x.x.x, 192.168.x.x, etc).
.IP
Use of the
.B prefix
directive is optional.  If it is not specified, all addresses to be translated
must be listed individually with the
.B map
directive.
.TP
.BI "map " "ipv4_address[/length] ipv6_address[/length]"
Creates a static mapping between RFC 7577 compliant hosts or subnets
.I ipv4_address[/length]
and
.I ipv6_address[/length]
to be used when translating IPv4 packets to IPv6 or IPv6 packets to IPv4.
If
.I /length
is not present, the
.I /length
after
.I ipv4_address
is treated as "/32" and that of
.I ipv6_address
as "/128".
Multiple
.B map
directives are permitted in the tayga.conf file.
.IP
.I ipv4_address
is permitted to overlap with the prefix specified in the
.B dynamic-pool
directive, in which case
.I ipv4_address
will be removed from the pool of available addresses.
.IP
.I ipv6_address
.B "must not"
overlap with the prefix specified in the
.B prefix
directive.
.TP
.BI "dynamic-pool " ipv4_address/length
Address prefix containing addresses available to be assigned to IPv6 hosts.
.I
length
must be 31 or less, as the lowest-numbered address in the prefix is considered
reserved and will not be used for dynamic assignment.
.IP
If TAYGA receives an IPv6 packet to be translated with an IPv6 source address
that does not match any existing mapping rules (as specified by the
.B map
directive or the
.B prefix
directive), TAYGA will create a dynamic mapping between the IPv6 address and
an IPv4 address drawn from the prefix specified by the
.B dynamic-pool
directive.  This mapping will be valid for two hours and four minutes after
the last packet matching the mapping is translated.
.IP
The
.B dynamic-pool
directive is optional.  If it is not specified, all IPv6 addresses appearing
in packets passing through TAYGA must match the NAT64 prefix or a static
mapping rule.
.TP
.BI "data-dir " path
The absolute path of a directory where TAYGA should store its data files.
Presently the only data file that TAYGA will store is the
.I dynamic.map
file, which tracks dynamic address assignments made from the dynamic pool.
.IP
.I path
is also the directory that will be used as a chroot(2) "jail" if the
.B \-\-chroot
command-line option is specified to the TAYGA daemon.
.IP
The TAYGA daemon must have full permissions (rwx) to
.I path
after it has dropped superuser privileges.  Generally this means that the
owner of
.I path
should be the user specified in the
.B \-\-user
command-line option.
.IP
The
.B data-dir
directive is optional, but without it, dynamic mappings will be lost when the
TAYGA daemon is stopped.  Also, use of the
.B \-\-chroot
command-line option will not be possible.
.TP
.BI "strict-frag-hdr " on|off|true|false|1|0
Flag to control whether TAYGA adds fragmentation headers to IPv6 packets that
do not require fragmentation.  RFC 6145 stipulates that the fragmentation
header SHOULD be added to all translated packets when the sender has not set
the DF (Don't Fragment) flag, to indicate that the sender allows fragmentation
and may not support path MTU discovery.  Unfortunately, some firewall
implementations drop IPv6 packets that are fragmented into a single fragment,
most notably Linux netfilter conntrack in kernels older than 2.6.34.
.IP
When
.B strict-frag-hdr
is set to 
.B true, on,
or
.B 1,
fragmentation headers will be added to all translated packets where the
DF bit in the original packet is clear.  This is the RFC-complaint behavior.
.IP
When
.B strict-frag-hdr
is set to 
.B false, off,
or
.B 0,
fragmentation headers will be suppressed when the translated packet fits
entirely within the IPv6 network MTU (1280 bytes).  This is the default
behavior.
.IP
This setting does not affect packets that arrive at TAYGA already fragmented,
or packets that must be fragmented to fit within the IPv6 network MTU.

.SH "SEE ALSO"
.BR tayga (8)
.br
.BR <http://www.litech.org/tayga/>