TAYGA.CONF(5)

🦋 tayga.conf — NAME 💖

ok so bestie, this is tayga.conf(5) — the config file of the TAYGA stateless NAT64 daemon. that's the vibe, that's the whole name section, slay. ✨

---

🌸 DESCRIPTION 🌸

This file holds the configuration parameters for the TAYGA stateless NAT64 daemon. It must exist and it must contain the mandatory configuration items, or TAYGA will flat-out refuse to run. no cap. 💀

The configuration directives are listed below. With the exception of the map directive, only one instance of each directive may appear in tayga.conf.

---

🎀 the directives 🎀

• tun-device device — Name of the network interface that's gonna be created by the kernel TUN module, so TAYGA can swap IPv4 and IPv6 packets with the in-kernel TCP/IP stack. 🫶
  • If device doesn't already exist as a persistent interface (created by the --mktun flag to tayga(8), for example), it gets created automatically when the TAYGA daemon starts, and destroyed when the daemon exits. it's giving temporary situationship, honestly.
  • Heads up bestie: TAYGA does not configure the host-side parameters of device. That's on the system administrator, using the ifconfig(8), route(8), and/or ip(8) commands. 👑
  • > This configuration directive is mandatory.
• ipv4-addr ipv4_address — The IPv4 address TAYGA uses 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 allowed to overlap with the prefix specified in the dynamic-pool directive, and if it does, ipv4_address gets removed from the pool of available addresses.
  • > This configuration directive is mandatory.
• ipv6-addr ipv6_address — The IPv6 address TAYGA uses 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 generates its IPv6 address by mapping the address specified in ipv4-addr into the NAT64 prefix. it's giving "i'll figure it out myself" energy.
• prefix ipv6_address/length — The 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. 📏
  • Using 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), unless the wkpf-strict option is set to no.
  • Use of the prefix directive is optional. If it's not specified, all addresses to be translated must be listed individually with the map directive.
• wkpf-strict yes|no — Enable or disable strict RFC 6052 compliance. If enabled, Tayga will refuse 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). 🚫
  • Enabled by default. ✨
• map ipv4_address[/length] ipv6_address[/length] — Creates a static mapping between RFC 7577 compliant hosts or subnets ipv4_address[/length] and ipv6_address[/length], to be used when translating IPv4 packets to IPv6 or IPv6 packets to IPv4. 🔁
  • If /length is not present, the /length after ipv4_address is treated as "/32" and that of ipv6_address as "/128".
  • Multiple map directives are permitted in the tayga.conf file. (this is the ONE directive that gets to be polyamorous, iykyk 💅)
  • 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, since the lowest-numbered address in the prefix is considered reserved and won't be used for dynamic assignment. 🙈
  • If TAYGA receives an IPv6 packet to be translated with an IPv6 source address that doesn't 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 stays valid for two hours and four minutes after the last packet matching the mapping is translated. ⏰
  • The dynamic-pool directive is optional. If it's 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 TAYGA stores 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 the owner of path should be the user specified in the --user command-line option.
  • The data-dir directive is optional. If not configured, TAYGA will check the environment variable STATE_DIRECTORY. If neither is provided, dynamic mappings will be lost when the TAYGA daemon is stopped. Also, use of the --chroot command-line option will not be possible. 😭
• udp-cksum-mode drop|fwd|calc — Handling of UDP packets with zero checksum. Per RFC7915, we can either [drop] the packet, or calculating [calc] a new checksum. Additionally, Tayga also allows the option of forwarding [fwd] the packet anyway. 🧮
• log drop|reject|self — Configure logging of packets. By default, Tayga only logs errors within Tayga itself. To log errors in packet translation, list one or more log option. 📝
  • drop — Log packets which were dropped.
  • reject — Log packets which were rejected (ICMP returned)
  • icmp — Log packets which returned an ICMP for any reason, including packets which are part of 'normal' internet traffic (i.e. Packet Too Big or Time Exceeded)
  • self — Log packets which were destined for Tayga itself
  • No packet logging is enabled by default. 🤫
• offlink-mtu bytes — Tayga will fragment IPv4->IPv6 packets which are larger than this size, unless the Don't Fragment bit is set. ✂️
  • IPv6 guarantees delivery of packets which are 1280 bytes or less. This behavior ensures that IPv4 packets will be delivered regardless of the MTU on subsequent links. IPv6 routers do not fragment packets which are too large, and IPv4 does not require Path MTU Discovery be used.
  • Increasing this limit will allow Tayga to translate packets which are larger than 1280 bytes, which may increase performance if you can guarantee that your network can transport packets up to this MTU end to end. 🔥
  • > Incorrectly setting this parameter may cause IPv4-translated packets to be dropped by IPv6 routers, in violation of expected IPv4 behavior. be careful bestie, this one bites. 💀

---

💜 SEE ALSO 💜

• tayga(8)
• <https://github.com/apalrd/tayga/>

---

and that's the whole page, periodt. 🎀 this was TAYGA 0.9.6, dated Jun 2025 — go forth and translate, bestie, you got this. 💖✨🦋