|IPv6 transition mechanisms|
|4in6||Tunneling from IPv4 to IPv6|
|6in4||Tunneling from IPv6 to IPv4|
|6over4||Transport of IPv6 data packets between dual-stack nodes over an IPv4 network|
|6to4||Transport of IPv6 data packets over an IPv4 network (obsolete)|
|AYIYA||Anything In Anything|
|Dual stack||Network nodes with IPv4 and IPv6 in parallel operation|
|Dual-Stack Lite (DS-Lite)||Like dual stack, but with global IPv6 and carrier NAT IPv4|
|6rd||IPv6 rapid deployment|
|ISATAP||Intra-Site Automatic Tunnel Addressing Protocol (deprecated)|
|Teredo||Encapsulation of IPv6 packets in IPv4 UDP -Datenpaketen|
|NAT64||Translation of IPv4 addresses into IPv6 addresses|
|464XLAT||Translation from IPv4 to IPv6 to IPv4 addresses|
|SIIT||Stateless IP / ICMP translation|
NAT64 is an IPv6 transition mechanism . It is used to translate IPv4 into IPv6 addresses. Its main purpose is to enable communication between hosts that can only be reached via IPv6 on the one hand and hosts that can only be reached via IPv4 on the other. In special cases it is possible to initiate a connection through IPv4 hosts, but this is normally reserved for IPv6 hosts. However, since there will be many more IPv6 hosts than IPv4 hosts in the foreseeable future, this is not a problem, since the main purpose is to address IPv4 servers from IPv6 networks.
NAT64 takes advantage of the fact that the 128-bit IPv6 addresses are well able to contain a 32-bit IPv4 address:
- IPv4: 192.0.2.1 → c0.00.02.01 ( hexadecimal notation of the IPv4 address)
- IPv6: 64: ff9b :: → 64: ff9b :: c000: 0201 (embedded in the last 32 bits of the IPv6 address)
The prefix 64: ff9b :: / 96 has been reserved specifically for this mechanism. As an alternative and for easier use, a mixed notation can be used instead of the purely hexadecimal notation:
- 192.0.2.1 → 64: ff9b :: 192.0.2.1
The decimal IPv4 address is automatically converted into hexadecimal notation by the IPv6 implementation.
If the IPv6 host 2001: db8 :: 1 wants to make contact with the IPv4 server 192.0.2.1 , it sends packets in its local network to the address 64: ff9b :: c000: 0201 . A static route that forwards all packets with the destination 64: ff9b :: / 96 to the NAT64 router would help here . The NAT64 router can now receive the packets, "unpack" the IPv4 address and forward the content from OSI layer 4 encapsulated in IPv4 packets via its IPv4 connection:
- IPv6 address: 64: ff9b :: c000: 0201 → IPv4 address (hex.): C0.00.02.01 → IPv4 address (dec.): 192.0.2.1
When using the prefixes you are not necessarily limited to 64: ff9b :: / 96 . With the appropriate configuration, you can use any subnet from your assigned network for this purpose.
NAT64 is stateful , which means that the NAT64 router remembers which IPv6 host and which IPv4 host are communicating with each other. This is kept in the router's NAT64 table. This works in a similar way to conventional NAT .
An example: If 2001: db8 :: dead: beef wants to establish a connection with 192.0.2.56, it sends (as usual) the packets that are intended for this host to 64: ff9b :: c000: 238 , i.e. im Basically the router. This takes the IPv4 address and routes the packets on, but remembers it
- the sender (source host)
- the recipient (destination host)
- the send port (TCP / UDP; source port)
- the recipient port (TCP / UDP; destination port)
If a packet with the opposite data arrives on the IPv4 side of the router , i.e. the sender and receiver have been swapped, the router knows immediately which IPv6 host it has to forward the packet to.
DNS64 is a technology that complements NAT64. It is defined in RFC 6147 and is based on DNS . A DNS64 server automatically and transparently generates AAAA RRs (AAAA: field name in DNS for IPv6 addresses) from A-Resource Records (A-RRs, i.e. DNS entries for IPv4 addresses). This works via the explained procedure:
- 2001: db8 :: 1 wants to contact the IPv4-only host host1.example.net . He does not know anything about the protocol support of this host as he only knows its name. He asks his name server 2001: db8 :: 2 for the address for host1.example.net
- His DNS64 name server 2001: db8 :: 2 first tries an AAAA resolution, but does not find a suitable entry (since host1.example.net does not have an IPv6 address). For this he receives an A record with the IPv4 address: 192.0.2.1 from the name server responsible for host1.example.net
- This address is now transformed into the IPv6 NAT64 form (which may be valid for this network): 64: ff9b :: 192.0.2.1 or 64: ff9b :: c000: 0201
- The DNS64 server now returns an AAAA-RR to the requesting host 2001: db8 :: 1 : 64: ff9b :: c000: 0201
- For him the whole thing is transparent. It considers the IPv6 address to be the valid address of host1.example.net and can now use this address to send IPv6 packets that are also transparently converted by the NAT64 router and sent to the destination host.
Advantages and disadvantages
For IPv6 hosts, NAT64 with DNS64 is a transparent and simple method of connecting both protocol worlds. When converting to NAT64 with DNS64, hosts only need to switch to a DNS64 name server, which in most environments can be done automatically via DHCPv6 or SLAAC with RFC 8106 .
The disadvantages of NAT64 result primarily from the fact that it is still a NAT procedure. If the provider uses a dynamic IPv4 address pool ( statesome or stateful NAT64 ), the connection must be established from the client, i. H. Server services are not possible on the customer side. This also includes peer-to-peer services. However, a dynamic IPv4 address pool is a prerequisite in order to save IPv4 addresses on the provider side, which is the advantage of NAT64 over dual-stack for providers .
NAT64 with DNS64 is based on the idea of returning an IPv6 address instead of an IPv4 address for a DNS request. If no names are used, but direct IPv4 addresses (for example URIs with numeric IPv4 addresses), no DNS request is made at all. Applications that use outdated programming interfaces incompatible with IPv6 cannot establish a connection either. These problems are solved by additional methods such as 464XLAT .
NAT64 in combination with DNS64 is suitable as a public offer, for example for providers. Only the DNS64 name server of this provider has to be entered in the clients to enable the connection with IPv4 hosts.
The packet filter pf from OpenBSD gained in the published along with OpenBSD 5.1 on 1 May 2012 Version support NAT64. The netfilter / iptables package still needs a patch for NAT64. Other open source NAT64 implementations as programs outside the kernel are TAYGA for Linux ( stateless ) and WrapSix ( stateful ) and within the kernel Jool (stateful) The name server software BIND supports DNS64.
- RFC 6146 - "Stateful NAT64". Describes the actual NAT64 mechanism
- RFC 6147 - "DNS64". Describes the DNS64 mechanism, which is important for the operation of NAT64