Provided by: tayga_0.9.2-6_amd64 bug

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/>