1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
Description: Use RFC 8215 WKP (64:ff9b:1::/48) by default
This lifts limitations regarding RFC 1918 addressing and allows starting
tayga by default in good conscience. Previously a prefix from the
2001:db8::/32 documentation prefix was used which users may confuse for a
viable default configuration despite this being a bogon network.
Origin: Debian
Forwarded: no
--- a/tayga.conf.example
+++ b/tayga.conf.example
@@ -41,7 +41,7 @@ ipv4-addr 192.168.255.1
# mandatory if the NAT64 prefix is 64:ff9b::/96 and ipv4-addr is a private
# (RFC1918) address.
#
-#ipv6-addr 2001:db8:1::2
+#ipv6-addr 64:ff9b:1::2
#
# The NAT64 prefix. The IPv4 address space is mapped into the IPv6 address
@@ -49,18 +49,17 @@ ipv4-addr 192.168.255.1
# recommended in most situations, but all lengths specified in RFC 6052 are
# supported.
#
-# This must be a prefix selected from your organization's IPv6 address space
-# or the Well-Known Prefix 64:ff9b::/96. Note that using the Well-Known
-# Prefix will prohibit IPv6 hosts from contacting IPv4 hosts that have private
-# (RFC1918) addresses, per RFC 6052.
+# This must be a prefix selected from your organization's IPv6 address
+# space or the RFC 8215 Well-Known Prefix 64:ff9b:1::/48. Note either
+# choice allows use of RFC 1918 addresses on the IPv4 side.
#
# The NAT64 prefix need not be specified if all required address mappings are
# listed in `map' directives. (See below.)
#
# Optional.
#
-prefix 2001:db8:1:ffff::/96
-# prefix 64:ff9b::/96
+prefix 64:ff9b:1::/96
+# prefix 2001:db8:1:ffff::/96
#
# Dynamic pool prefix. IPv6 hosts which send traffic through TAYGA (and do
@@ -97,6 +96,6 @@ data-dir /var/spool/tayga
#
# Optional.
#
-#map 192.168.5.42 2001:db8:1:4444::1
-#map 192.168.5.43 2001:db8:1:4444::2
-#map 192.168.255.2 2001:db8:1:569::143
+#map 192.168.5.42 64:ff9b:1:4444::1
+#map 192.168.5.43 64:ff9b:1:4444::2
+#map 192.168.255.2 64:ff9b:1:569::143
--- a/README
+++ b/README
@@ -2,7 +2,7 @@
README for TAYGA v0.9.2
******************************************************************************
-Last updated 2010-12-12
+Last updated 2025-11-14
--------
Overview
@@ -59,20 +59,22 @@ states that a 32-bit IPv4 address should
prefix, which we call the NAT64 prefix, and the resulting IPv6 address can be
used to contact the IPv4 host through the NAT64.
-The NAT64 prefix should be assigned out of a site's global IPv6 address
-allocation. For example, if a site is allocated 2001:db8:1::/48, the prefix
-2001:db8:1:ffff::/96 could be set aside for NAT64. (There are several options
-for the length of the NAT64 prefix, but a /96 is recommended.) The IPv4 host
-198.51.100.10 could then be accessed through the NAT64 using the address
-2001:db8:1:ffff::c633:640a. Conveniently, it is possible to use the syntax
+The NAT64 prefix should be assigned out of the RFC 8215 well-known prefix:
+64:ff9b:1::/48. Do not confuse this with the RFC 6052 well-known prefix:
+64:ff9b::/96! This older /96 prefix allocation is adjacent but distinct
+from the newer /48 prefix, but since it prohibits the use of private IPv4
+(RFC 1918) address space on the IPv4 side of the translator it's often too
+limiting.
+
+Alternatively a network specific prefix can be carved from your site's
+global IPv6 address allocation: For example, if your site was allocated
+2001:db8:1::/48, the prefix 2001:db8:1:ffff::/96 could be set aside for
+NAT64. (There are several options for the length of the NAT64 prefix, but
+a /96 is recommended.) The IPv4 host 198.51.100.10 could then be accessed
+through the NAT64 using the address 2001:db8:1:ffff::c633:640a.
+Conveniently, it is possible to use the syntax
2001:db8:1:ffff::198.51.100.10 instead.
-RFC 6052 also specifies a Well-Known Prefix 64:ff9b::/96 which can be used for
-NAT64 service rather than allocating a prefix from the site's IPv6 address
-block. However, this comes with several restrictions, primarily that hosts
-with private IPv4 addresses (10.x.x.x, 192.168.x.x, etc) cannot be accessed
-through the NAT64. See RFC 6052 for more information.
-
If NAT64 service is needed for only a few hosts instead of the entire IPv4
address space, TAYGA can be configured without a NAT64 prefix, and address
maps can be assigned on a host-by-host basis.
@@ -129,8 +131,7 @@ site. Here is a sample minimal configur
tun-device nat64
ipv4-addr 192.168.255.1
- prefix 2001:db8:1:ffff::/96 # replace with a prefix from
- # your site's address range
+ prefix 64:ff9b:1::/96
dynamic-pool 192.168.255.0/24
data-dir /var/db/tayga # omit if you do not need persistent
# dynamic address maps
@@ -146,15 +147,13 @@ continuing. Otherwise, the new nat64 in
proper routes can be added to your system:
# ip link set nat64 up
- # ip addr add 2001:db8:1::1 dev nat64 # replace with your router's address
- # ip addr add 192.168.0.1 dev nat64 # replace with your router's address
- # ip route add 2001:db8:1:ffff::/96 dev nat64 # from tayga.conf
- # ip route add 192.168.255.0/24 dev nat64 # from tayga.conf
+ # ip route add 64:ff9b:1::/96 dev nat64 # from tayga.conf
+ # ip route add 192.168.255.0/24 dev nat64 # from tayga.conf
Firewalling your NAT64 prefix from outside access is highly recommended:
- # ip6tables -A FORWARD -s 2001:db8:1::/48 -d 2001:db8:1:ffff::/96 -j ACCEPT
- # ip6tables -A FORWARD -d 2001:db8:1:ffff::/96 -j DROP
+ # ip6tables -A FORWARD -s 2001:db8:1::/48 -d 64:ff9b:1::/96 -j ACCEPT
+ # ip6tables -A FORWARD -d 64:ff9b:1::/96 -j DROP
At this point, you may start the tayga process:
|
