10.0.0.21 Git - 6bed4/blob - 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