Migration to GitLab
[6bed4] / NAT64.MD
1 IPv6-only networks: Add NAT64, DNS64 and 6bed4
2
3 > *Imagine a new server setup with only IPv6.  Less complexity,
4 > plenty of address space, global uniqueness and not the dual
5 > nature that confuses debugging.  But how to deal with IPv4
6 > clients?*
7
8
9 There are a few translation mechanisms for IPv4/IPv6, and the
10 stateless translation of address headers with NAT64 is perhaps
11 the simplest.  Generally put, IPv4 addresses receive a /96
12 prefix that makes them into IPv6 addresses, and local routing
13 brings traffic back to the NAT64 router for translating back
14 and delivery over IPv4 of the response.
15
16 NAT64 works in conjunction with DNS64, which translates A
17 query output to AAAA query output (if no direct addresses are
18 usable).  The /96 prefix used there is set to the same value
19 as the one added by NAT64, so the forged AAAA records pass
20 out through the translator and end up in the right IPv4
21 address.  DNS64 conflicts with DNSSEC, but its mapping may
22 be applied after secure query processing.
23
24 Given the small space available in IPv4, there are likely to
25 be more multiplexing mechanisms, such as based on SRV records,
26 hostnames such as in HTTP or Server Name Indications such as
27 in TLS.  This may be done after the translation by NAT64 into
28 the IPv6 space, so redirection can be made to one of the many
29 addresses then available.
30
31 IPv4 does need NAT, and certainly on clients it is commonly
32 employed.  This means that port numbers can change between
33 the client and server end points, and so peer-to-peer traffic
34 is not as reliable as on IPv6, where addresses and ports are
35 transparant, and only firewall-based filtering is used.
36 This gives much more reliable peer-to-peer performance, and
37 is preferred for the more advanced use cases.
38
39 NAT64 will not be helpful for such situations, but 6bed4 is.
40 The ability to send an IPv6 address in end-to-end communication,
41 based on prior contact to a server, should help to build up
42 reliable communication even if it actually runs over IPv4 and
43 UDP.  The UDP port will not get renumbered; if that is the only
44 option, the 6bed4 system falls back to relaying through the
45 server that originally saw the IPv4 address and UDP port.  This
46 would be rare, but it is a reassurance that it exists.  With
47 6bed4 it should therefore be possible to engage in full-blown
48 peer-to-peer operations, and almost always enjoy the benefits
49 of direct communication between the peers.
50
51 In a scenario where a server employs NAT64 and 6bed4 service
52 at the entrance, this is even more straightforward, as the
53 6bed4 service would use its own IPv4 address in its endpoint
54 address, and mention it again in the low half to hint that
55 direct contact is the proper mechanism to use.  The peering
56 does get possible when the protocol connects parties that
57 connect through these addresses, but if it fails then the
58 server will be available for bouncing traffic between peers.
59
60 DNS64 plays no role in the 6bed4 scenario.  Servers that
61 exhibit 6bed4 service announce their IPv6 address for the
62 6bed4 service end point as an AAAA record.
63
64 **Summary:** NAT64+DNS64 is useful for backward compatibility
65 with client-server mode; for peer-to-peer operation however,
66 6bed4 is a more reliable form.  Clients can upgrade to the
67 more reliable service by installing the 6bed4peer, but they
68 are free to try a service without that explicit action.
69