1TAYGA.CONF(5) TAYGA.CONF(5)
2
6 tayga.conf - configuration file of the TAYGA stateless NAT64 daemon
7
9 This file contains the configuration parameters for the TAYGA stateless
10 NAT64 daemon. It must exist and contain the mandatory configuration
11 items or TAYGA will refuse to run.
12 The configuration directives are listed below. With the exception of
14 the map directive, only one instance of each directive may appear in
15 tayga.conf.
16 tun-device device
18 Name of the network interface that will be created by the kernel
19 TUN module for TAYGA to exchange IPv4 and IPv6 packets with the
20 in-kernel TCP/IP stack. If device does not already exist as a
21 persistent interface (created by the --mktun flag to tayga(8),
22 for example), it will be created automatically when the TAYGA
23 daemon starts and destroyed when the daemon exits.
24 Note that TAYGA does not configure the host-side parameters of
26 device. This must be done by the system administrator using the
27 ifconfig(8), route(8), and/or ip(8) commands.
28 This configuration directive is mandatory.
30 ipv4-addr ipv4_address
32 IPv4 address that TAYGA will use as the source address for
33 ICMPv4 errors generated by the translation process. TAYGA will
34 also respond to ICMP echo requests (pings) at this address.
35 ipv4_address is permitted to overlap with the prefix specified
37 in the dynamic-pool directive, in which case ipv4_address will
38 be removed from the pool of available addresses.
39 This configuration directive is mandatory.
41 ipv6-addr ipv6_address
43 IPv6 address that TAYGA will use as the source address for
44 ICMPv6 errors generated by the translation process. TAYGA will
45 also respond to ICMPv6 echo requests (pings) at this address.
46 This configuration directive is mandatory unless the NAT64 pre‐
48 fix is specified with the prefix directive, in which case TAYGA
49 will generate its IPv6 address by mapping the address specified
50 in ipv4-addr into the NAT64 prefix.
51 prefix ipv6_address/length
53 NAT64 prefix for mapping IPv4 addresses into the IPv6 address
54 space. TAYGA performs address translation as specified in RFC
55 6052, and only prefix lengths allowed in that document will be
56 permitted in the prefix directive.
57 The use of either a Network-Specific Prefix or the Well-Known
59 Prefix (64:ff9b::/96) is allowed, however, as required by RFC
60 6052, TAYGA will refuse to translate packets with a source or
61 destination address composed of the Well-Known Prefix and a non-
62 global IPv4 address (10.x.x.x, 192.168.x.x, etc).
63 Use of the prefix directive is optional. If it is not speci‐
65 fied, all addresses to be translated must be listed individually
66 with the map directive.
67 map ipv4_address ipv6_address
69 Creates a static mapping between ipv4_address and ipv6_address
70 to be used when translating IPv4 packets to IPv6 or IPv6 packets
71 to IPv4. Multiple map directives are permitted in the
72 tayga.conf file.
73 ipv4_address is permitted to overlap with the prefix specified
75 in the dynamic-pool directive, in which case ipv4_address will
76 be removed from the pool of available addresses.
77 ipv6_address must not overlap with the prefix specified in the
79 prefix directive.
80 dynamic-pool ipv4_address/length
82 Address prefix containing addresses available to be assigned to
83 IPv6 hosts. length must be 31 or less, as the lowest-numbered
84 address in the prefix is considered reserved and will not be
85 used for dynamic assignment.
86 If TAYGA receives an IPv6 packet to be translated with an IPv6
88 source address that does not match any existing mapping rules
89 (as specified by the map directive or the prefix directive),
90 TAYGA will create a dynamic mapping between the IPv6 address and
91 an IPv4 address drawn from the prefix specified by the dynamic-
92 pool directive. This mapping will be valid for two hours and
93 four minutes after the last packet matching the mapping is
94 translated.
95 The dynamic-pool directive is optional. If it is not specified,
97 all IPv6 addresses appearing in packets passing through TAYGA
98 must match the NAT64 prefix or a static mapping rule.
99 data-dir path
101 The absolute path of a directory where TAYGA should store its
102 data files. Presently the only data file that TAYGA will store
103 is the dynamic.map file, which tracks dynamic address assign‐
104 ments made from the dynamic pool.
105 path is also the directory that will be used as a chroot(2)
107 "jail" if the --chroot command-line option is specified to the
108 TAYGA daemon.
109 The TAYGA daemon must have full permissions (rwx) to path after
111 it has dropped superuser privileges. Generally this means that
112 the owner of path should be the user specified in the --user
113 command-line option.
114 The data-dir directive is optional, but without it, dynamic map‐
116 pings will be lost when the TAYGA daemon is stopped. Also, use
117 of the --chroot command-line option will not be possible.
118 strict-frag-hdr on|off|true|false|1|0
120 Flag to control whether TAYGA adds fragmentation headers to IPv6
121 packets that do not require fragmentation. RFC 6145 stipulates
122 that the fragmentation header SHOULD be added to all translated
123 packets when the sender has not set the DF (Don't Fragment)
124 flag, to indicate that the sender allows fragmentation and may
125 not support path MTU discovery. Unfortunately, some firewall
126 implementations drop IPv6 packets that are fragmented into a
127 single fragment, most notably Linux netfilter conntrack in ker‐
128 nels older than 2.6.34.
129 When strict-frag-hdr is set to true, on, or 1, fragmentation
131 headers will be added to all translated packets where the DF bit
132 in the original packet is clear. This is the RFC-complaint
133 behavior.
134 When strict-frag-hdr is set to false, off, or 0, fragmentation
136 headers will be suppressed when the translated packet fits
137 entirely within the IPv6 network MTU (1280 bytes). This is the
138 default behavior.
139 This setting does not affect packets that arrive at TAYGA
141 already fragmented, or packets that must be fragmented to fit
142 within the IPv6 network MTU.
143
146 tayga(8)
147 <http://www.litech.org/tayga/>
148TAYGA 0.9.2 June 2011 TAYGA.CONF(5)