Provided by: tayga_0.9.2-2_i386 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/>