Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
TAYGA.CONF(5)							 TAYGA.CONF(5)

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  pre-
	      fix  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	speci-
	      fied, 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  assign-
	      ments 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 map-
	      pings  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 ker-
	      nels 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  be-
	      havior.

	      When  strict-frag-hdr  is	set to false, off, or 0, fragmentation
	      headers will be suppressed when the translated packet  fits  en-
	      tirely  within  the  IPv6	network	MTU (1280 bytes).  This	is the
	      default behavior.

	      This setting does	not affect packets that	arrive	at  TAYGA  al-
	      ready  fragmented,  or  packets  that  must be fragmented	to fit
	      within the IPv6 network MTU.

SEE ALSO
       tayga(8)
       <http://www.litech.org/tayga/>

TAYGA 0.9.2			   June	2011			 TAYGA.CONF(5)

NAME | DESCRIPTION | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=tayga.conf&sektion=5&manpath=FreeBSD+13.0-RELEASE+and+Ports>

home | help