NAME¶
tayga.conf - configuration file of the TAYGA stateless NAT64 daemon
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.
The configuration directives are listed below. With the exception of the
map directive, only one instance of each directive may appear in
tayga.conf.
- 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 device does not already exist as a
persistent interface (created by the --mktun flag to tayga(8), for
example), it will be created automatically when the TAYGA daemon starts
and destroyed when the daemon exits.
- Note that TAYGA does not configure the host-side parameters
of device. This must be done by the system administrator using the
ifconfig(8), route(8), and/or ip(8) commands.
- This configuration directive is mandatory.
- 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.
- ipv4_address is permitted to overlap with the prefix
specified in the dynamic-pool directive, in which case
ipv4_address will be removed from the pool of available
addresses.
- This configuration directive is mandatory.
- 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.
- This configuration directive is mandatory unless the NAT64
prefix is specified with the prefix directive, in which case TAYGA
will generate its IPv6 address by mapping the address specified in
ipv4-addr into the NAT64 prefix.
- 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 prefix directive.
- The use of either a Network-Specific Prefix or the
Well-Known Prefix (64:ff9b::/96) is allowed, 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).
- Use of the prefix directive is optional. If it is
not specified, all addresses to be translated must be listed individually
with the map directive.
- map ipv4_address ipv6_address
- Creates a static mapping between ipv4_address and
ipv6_address to be used when translating IPv4 packets to IPv6 or
IPv6 packets to IPv4. Multiple map directives are permitted in the
tayga.conf file.
- ipv4_address is permitted to overlap with the prefix
specified in the dynamic-pool directive, in which case
ipv4_address will be removed from the pool of available
addresses.
- ipv6_address must not overlap with the prefix
specified in the prefix directive.
- dynamic-pool ipv4_address/length
- Address prefix containing addresses available to be
assigned to IPv6 hosts. 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.
- 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 map directive or the prefix directive),
TAYGA will create a dynamic mapping between the IPv6 address and an IPv4
address drawn from the prefix specified by the dynamic-pool
directive. This mapping will be valid for two hours and four minutes after
the last packet matching the mapping is translated.
- The 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.
- 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
dynamic.map file, which tracks dynamic address assignments made
from the dynamic pool.
- path is also the directory that will be used as a
chroot(2) "jail" if the --chroot command-line option is
specified to the TAYGA daemon.
- The TAYGA daemon must have full permissions (rwx) to
path after it has dropped superuser privileges. Generally this
means that the owner of path should be the user specified in the
--user command-line option.
- The data-dir directive is optional, but without it,
dynamic mappings will be lost when the TAYGA daemon is stopped. Also, use
of the --chroot command-line option will not be possible.
- 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.
- When strict-frag-hdr is set to true, on, or
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.
- When strict-frag-hdr is set to false, off, or
0, fragmentation headers will be suppressed when the translated
packet fits entirely within the IPv6 network MTU (1280 bytes). This is the
default behavior.
- 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.
SEE ALSO¶
tayga(8)
<http://www.litech.org/tayga/>