{"id":19640030,"url":"https://github.com/openthread/tayga","last_synced_at":"2025-04-28T11:31:01.506Z","repository":{"id":34401996,"uuid":"155594194","full_name":"openthread/tayga","owner":"openthread","description":null,"archived":true,"fork":false,"pushed_at":"2022-03-23T00:58:23.000Z","size":110,"stargazers_count":49,"open_issues_count":0,"forks_count":9,"subscribers_count":18,"default_branch":"master","last_synced_at":"2025-04-05T08:25:36.280Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/openthread.png","metadata":{"files":{"readme":"README","changelog":null,"contributing":null,"funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2018-10-31T17:02:23.000Z","updated_at":"2025-04-03T16:59:48.000Z","dependencies_parsed_at":"2022-08-08T01:00:27.631Z","dependency_job_id":null,"html_url":"https://github.com/openthread/tayga","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openthread%2Ftayga","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openthread%2Ftayga/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openthread%2Ftayga/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openthread%2Ftayga/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/openthread","download_url":"https://codeload.github.com/openthread/tayga/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":251304762,"owners_count":21567932,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-11T14:04:26.168Z","updated_at":"2025-04-28T11:30:58.326Z","avatar_url":"https://github.com/openthread.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"******************************************************************************\n                           README for TAYGA v0.9.2\n******************************************************************************\n\nLast updated 2010-12-12\n\n--------\nOverview\n--------\n\nTAYGA is an out-of-kernel stateless NAT64 implementation for Linux.  It uses\nthe TUN driver to exchange packets with the kernel, which is the same driver\nused by OpenVPN and QEMU/KVM.  TAYGA needs no kernel patches or out-of-tree\nmodules, and it is compatible with all 2.4 and 2.6 kernels.\n\nIf you're impatient and you know what stateless NAT64 is, you can skip to the\nInstallation \u0026 Basic Configuration section.\n\n-------------------------------\nStateless versus Stateful NAT64\n-------------------------------\n\nMost people are familiar with stateful NAT, which allows N:1 address mapping\nby tracking TCP and UDP sessions and rewriting port numbers on each packet.\nMost commonly this is used to translate sessions from multiple \"internal\"\nhosts (which are numbered with private IPv4 addresses) onto a single global\nIPv4 address on the NAT device's \"external\" interface.\n\nStateless NAT does no such session tracking or port number rewriting.  It\nsimply performs a 1:1 substitution of IP addresses using a mapping table\nprovided by the network administrator.  For example, an organization whose\nglobal address allocation was 198.51.100.0/24 but whose hosts were using\naddresses in 192.0.2.0/24 could use a stateless NAT to rewrite 192.0.2.1 into\n198.51.100.1, 192.0.2.35 into 198.51.100.35, etc, in the outbound direction,\nand the reverse in the inbound direction.  This is commonly done when an\norganization moves to a new ISP and receives a new IPv4 address delegation of\nthe same size as their old delegation but does not want to renumber their\nnetwork.\n\nTAYGA and other stateless NAT64 translators operate in this fashion.  When\ntranslating packets between IPv4 and IPv6, the source and destination\naddresses in the packet headers are substituted using a 1:1 mapping.  This\nmeans that, in order to exchange packets across the NAT64, each IPv4 host must\nbe represented by a unique IPv6 address, and each IPv6 host must be\nrepresented by a unique IPv4 address.  How this mapping is performed is\ndiscussed in the next sections.\n\nIn situations where stateful NAT64 is required, TAYGA can be used in\ncombination with a stateful IPv4 NAT such as the iptables MASQUERADE target.\nThis allows the administrator a great deal more flexibility than if stateful\nNAT were implemented directly in TAYGA.\n\n----------------------\nMapping IPv4 into IPv6\n----------------------\n\nTAYGA maps IPv4 addresses into the IPv6 network according to RFC 6052.  This\nstates that a 32-bit IPv4 address should be appended to a designated IPv6\nprefix, which we call the NAT64 prefix, and the resulting IPv6 address can be\nused to contact the IPv4 host through the NAT64.\n\nThe NAT64 prefix should be assigned out of a site's global IPv6 address\nallocation.  For example, if a site is allocated 2001:db8:1::/48, the prefix\n2001:db8:1:ffff::/96 could be set aside for NAT64.  (There are several options\nfor the length of the NAT64 prefix, but a /96 is recommended.)  The IPv4 host\n198.51.100.10 could then be accessed through the NAT64 using the address\n2001:db8:1:ffff::c633:640a.  Conveniently, it is possible to use the syntax\n2001:db8:1:ffff::198.51.100.10 instead.\n\nRFC 6052 also specifies a Well-Known Prefix 64:ff9b::/96 which can be used for\nNAT64 service rather than allocating a prefix from the site's IPv6 address\nblock.  However, this comes with several restrictions, primarily that hosts\nwith private IPv4 addresses (10.x.x.x, 192.168.x.x, etc) cannot be accessed\nthrough the NAT64.  See RFC 6052 for more information.\n\nIf NAT64 service is needed for only a few hosts instead of the entire IPv4\naddress space, TAYGA can be configured without a NAT64 prefix, and address\nmaps can be assigned on a host-by-host basis.\n\n----------------------\nMapping IPv6 into IPv4\n----------------------\n\nBeing a stateless NAT, TAYGA requires that a unique IPv4 address is assigned\nto every IPv6 host that needs NAT64 service.  This assignment can be done\nstatically by the network administrator, or dynamically by TAYGA from a pool\nof IPv4 addresses designated for this purpose.\n\nStatic address mapping is desirable for servers or other hosts requiring a\nwell-known address.  Statically mapped addresses may be entered into DNS, for\nexample.\n\nDynamic address mapping allows TAYGA to assign IPv4 addresses to IPv6 hosts as\nthey are needed.  By default, these assignments are guaranteed to remain\nusable for up to two hours after the last packet seen, but they are retained\nfor up to two weeks as long as the address pool does not become empty.\nAssignments are written to disk so they persist through a restart of the TAYGA\ndaemon, allowing existing TCP and UDP sessions to continue uninterrupted.\n\n(Of course, TAYGA also supports the addressing architecture described in RFC\n6052 in which IPv6 hosts are numbered with \"IPv4-translatable IPv6 addresses\"\ncarved out of the NAT64 prefix.)\n\n----------------------------------\nInstallation \u0026 Basic Configuration\n----------------------------------\n\nTAYGA uses the GNU Automake/Autoconf system, which requires the `configure`\nscript to be run to generate the Makefile prior to building.  The --prefix\nand/or --sysconfdir options can be specified to the configure script to\nspecify the top-level installation path and tayga.conf file directory,\nrespectively.\n\nAfter unpacking the distribution tar.bz2 file, run:\n\n  # ./configure \u0026\u0026 make \u0026\u0026 make install\n\nThis will install the tayga executable in /usr/local/sbin/tayga and the sample\nconfig file in /usr/local/etc/tayga.conf.example.\n\nNext, if you would like dynamic maps to be persistent between TAYGA restarts,\ncreate a directory to store the dynamic.map file:\n\n  # mkdir -p /var/db/tayga\n\nNow create your site-specific tayga.conf configuration file.  The installed\ntayga.conf.example file can be copied to tayga.conf and modified to suit your\nsite.  Here is a sample minimal configuration:\n\n  tun-device nat64\n  ipv4-addr 192.168.255.1\n  prefix 2001:db8:1:ffff::/96     # replace with a prefix from\n                                  # your site's address range\n  dynamic-pool 192.168.255.0/24\n  data-dir /var/db/tayga          # omit if you do not need persistent\n                                  # dynamic address maps\n\nBefore starting the TAYGA daemon, the routing setup on your system will need\nto be changed to send IPv4 and IPv6 packets to TAYGA.  First create the TUN\nnetwork interface:\n\n  # tayga --mktun\n\nIf TAYGA prints any errors, you will need to fix your config file before\ncontinuing.  Otherwise, the new nat64 interface can be configured and the\nproper routes can be added to your system:\n\n  # ip link set nat64 up\n  # ip addr add 2001:db8:1::1 dev nat64  # replace with your router's address\n  # ip addr add 192.168.0.1 dev nat64    # replace with your router's address\n  # ip route add 2001:db8:1:ffff::/96 dev nat64  # from tayga.conf\n  # ip route add 192.168.255.0/24 dev nat64      # from tayga.conf\n\nFirewalling your NAT64 prefix from outside access is highly recommended:\n\n  # ip6tables -A FORWARD -s 2001:db8:1::/48 -d 2001:db8:1:ffff::/96 -j ACCEPT\n  # ip6tables -A FORWARD -d 2001:db8:1:ffff::/96 -j DROP\n\nAt this point, you may start the tayga process:\n\n  # tayga\n\nCheck your system log (/var/log/syslog or /var/log/messages) for status\ninformation.\n\nIf you are having difficulty configuring TAYGA, use the -d option to run the\ntayga process in the foreground and send all log messages to stdout:\n\n  # tayga -d\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenthread%2Ftayga","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fopenthread%2Ftayga","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenthread%2Ftayga/lists"}