TAYGA(8)

πŸ’– TAYGA(8) β€” stateless NAT64 daemon πŸ’–

okay bestie, sit DOWN, because this one is a whole vibe. it's tayga, section 8 of the manual (that's the sysadmin section, iykyk), and she is a stateless NAT64 daemon. yes really. let's get into it ✨


🌸 SYNOPSIS 🌸

tayga [OPTION]...

tayga --mktun [OPTION]...

tayga --rmtun [OPTION]...

three whole modes, three whole moods πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

so. TAYGA is a stateless NAT64 daemon for Linux and FreeBSD. she uses the in-kernel TUN network driver, which means TAYGA receives IPv4 and IPv6 packets straight from the host's network stack, translates them into the other protocol, and then sends the translated packets right back to the host using that same TUN interface. it's giving middle school note-passing but make it networking 🫢

the translation is compliant with IETF RFC 7915, and address mapping is done in accordance with RFC 6052 and RFC 7757. no cap. and optionally? TAYGA can be configured to dynamically map IPv6 hosts to addresses drawn from a configured IPv4 address pool. flexible queen πŸ‘‘

okay now the important part. as a stateless NAT, TAYGA requires a one-to-one mapping between IPv4 addresses and IPv6 addresses. like, one for one, no sharing, that's the rule πŸ“

so what if you do want to map multiple IPv6 addresses onto a single IPv4 address? totally doable, but it's a two-step: map the IPv6 addresses to private IPv4 addresses with TAYGA, and then use a stateful NAT44 (think the iptables(8) MASQUERADE target) to map those private IPv4 addresses onto the single IPv4 address you actually want. teamwork makes the dream work πŸ’«

TAYGA's configuration lives in the tayga.conf(5) file, which is usually found at /etc/tayga.conf or /usr/local/etc/tayga.conf. go find her πŸŽ€


✨ INVOCATION ✨

without the --mktun or --rmtun options, the tayga executable runs as a daemon, translating packets exactly like we just described. main character behaviour, honestly.

the --mktun and --rmtun options tell TAYGA to create or destroy, respectively, its configured TUN device as a "persistent" interface β€” and then it immediately exits. like, does the thing and leaves. iconic πŸšͺπŸ’¨

now, persistent TUN devices stay present on the host system even when TAYGA is not running. that's the whole point, bestie: it lets you set up host-side network parameters and firewall rules before packet translation even starts. this can simplify network configuration on the host β€” for example, systems that use a Debian-style /etc/network/interfaces file can configure TAYGA's TUN device at boot by running tayga --mktun as a "pre-up" command and then configuring the TUN device like it's any other network interface. chef's kiss πŸ‘©β€πŸ³πŸ’‹


πŸ’… OPTIONS πŸ’…

  • -c configfile | --config configfile β€” Read configuration options from configfile. tell her where the config lives πŸ—‚οΈ
  • -d β€” Enable debug messages (this enables --nodetach as well, so buckle up)
  • -n | --nodetach β€” Do not detach from terminal. stay right here with me πŸ₯Ί
  • -u userid | --user userid β€” Set uid to userid after initialization
  • -g groupid | --group groupid β€” Set gid to groupid after initialization
  • -r | --chroot β€” chroot() to data-dir (specified in config file). jail time, but make it security πŸ”’
  • -p pidfile | --pidfile pidfile β€” Write process ID of daemon to pidfile

🌈 AUTHOR 🌈

Maintained by Andrew Palardy <andrew@apalrd.net>. thank you for your service 🫑


Copyright Β© 2010 Nathan Lutchansky Copyright Β© 2025 Andrew Palardy

License GPLv2+: GNU GPL version 2 or later

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. fr fr, read that part twice πŸ’€

⭐ SEE ALSO ⭐


and that's the whole page, bestie πŸ¦‹ go forth and translate some packets. this was TAYGA 0.9.4, from Jun 2025, and she ate πŸ’–βœ¨πŸ‘‘