186 lines
6.1 KiB
Groff
186 lines
6.1 KiB
Groff
.TH TAYGA.CONF "5" "June 2011" "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 ipv6_address"
|
|
Creates a static mapping between
|
|
.I ipv4_address
|
|
and
|
|
.I ipv6_address
|
|
to be used when translating IPv4 packets to IPv6 or IPv6 packets to IPv4.
|
|
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/>
|