7. Deployment Scenarios and Examples
In this section, we illustrate how the DNS64 behaves in different scenarios that are expected to be common. In particular, we will consider the following scenarios defined in [RFC6144]: the "an IPv6 network to the IPv4 Internet" scenario (both with DNS64 in DNS server mode and in stub-resolver mode) and the "IPv6 Internet to an IPv4 network" setup (with DNS64 in DNS server mode only).
In all the examples below, there is an IPv6/IPv4 translator connecting the IPv6 domain to the IPv4 one. Also, there is a name server that is a dual-stack node, so it can communicate with IPv6 hosts using IPv6 and with IPv4 nodes using IPv4. In addition, we assume that in the examples, the DNS64 function learns which IPv6 prefix it needs to use to map the IPv4 address space through manual configuration.
7.1. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 in DNS Server Mode
In this example, we consider an IPv6 node located in an IPv6-only site that initiates a communication to an IPv4 node located in the IPv4 Internet.
The scenario for this case is depicted in the following figure:
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +-------------+ | Internet |
| |--| Name server |--| |
| | | with DNS64 | | +----+ |
| +----+ | +-------------+ | | H2 | |
| | H1 |---| | | +----+ |
| +----+ | +------------+ | 192.0.2.1 |
| |---| IPv6/IPv4 |--| |
| | | Translator | | |
| | +------------+ | |
| | | | |
+---------------------+ +---------------+
Figure 4: "An IPv6 Network to the IPv4 Internet" Setup with DNS64 in DNS Server Mode
The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN h2.example.com.
The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned to its IPv4 interface, and it is using the Well-Known Prefix 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The same prefix is configured in the DNS64 function in the local name server.
For this example, assume the typical DNS situation where IPv6 hosts have only stub resolvers, and they are configured with the IP address of a name server that they always have to query and that performs recursive lookups (henceforth called "the recursive name server").
The steps by which H1 establishes communication with H2 are:
-
H1 does a DNS lookup for h2.example.com. H1 does this by sending a DNS query for a AAAA record for H2 to the recursive name server. The recursive name server implements DNS64 functionality.
-
The recursive name server resolves the query, and discovers that there are no AAAA records for H2.
-
The recursive name server performs an A-record query for H2 and gets back an RRSet containing a single A record with the IPv4 address 192.0.2.1. The name server then synthesizes a AAAA record. The IPv6 address in the AAAA record contains the prefix assigned to the IPv6/IPv4 translator in the upper 96 bits and the received IPv4 address in the lower 32 bits; i.e., the resulting IPv6 address is 64:ff9b::192.0.2.1.
-
H1 receives the synthetic AAAA record and sends a packet towards H2. The packet is sent to the destination address 64:ff9b:: 192.0.2.1.
-
The packet is routed to the IPv6 interface of the IPv6/IPv4 translator, and the subsequent communication flows by means of the IPv6/IPv4 translator mechanisms.
7.2. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 in Stub-Resolver Mode
This case is depicted in the following figure:
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +--------+ | Internet |
| |-----| Name |----| |
| +-----+ | | server | | +----+ |
| | H1 | | +--------+ | | H2 | |
| |with |---| | | +----+ |
| |DNS64| | +------------+ | 192.0.2.1 |
| +----+ |---| IPv6/IPv4 |--| |
| | | Translator | | |
| | +------------+ | |
| | | | |
+---------------------+ +---------------+
Figure 5: "An IPv6 Network to the IPv4 Internet" Setup with DNS64 in Stub-Resolver Mode
The figure shows an IPv6 node H1 implementing the DNS64 function and an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN h2.example.com.
The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned to its IPv4 interface, and it is using the Well-Known Prefix 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The same prefix is configured in the DNS64 function in H1.
For this example, assume the typical DNS situation where IPv6 hosts have only stub resolvers, and they are configured with the IP address of a name server that they always have to query and that performs recursive lookups (henceforth called "the recursive name server"). The recursive name server does not perform the DNS64 function.
The steps by which H1 establishes communication with H2 are:
-
H1 does a DNS lookup for h2.example.com. H1 does this by sending a DNS query for a AAAA record for H2 to the recursive name server.
-
The recursive DNS server resolves the query, and returns the answer to H1. Because there are no AAAA records in the global DNS for H2, the answer is empty.
-
The stub resolver at H1 then queries for an A record for H2 and gets back an A record containing the IPv4 address 192.0.2.1. The DNS64 function within H1 then synthesizes a AAAA record. The IPv6 address in the AAAA record contains the prefix assigned to the IPv6/IPv4 translator in the upper 96 bits, then the received IPv4 address in the lower 32 bits; the resulting IPv6 address is 64:ff9b::192.0.2.1.
-
H1 sends a packet towards H2. The packet is sent to the destination address 64:ff9b::192.0.2.1.
-
The packet is routed to the IPv6 interface of the IPv6/IPv4 translator and the subsequent communication flows using the IPv6/ IPv4 translator mechanisms.
7.3. Example of "the IPv6 Internet to an IPv4 Network" Setup with DNS64 in DNS Server Mode
In this example, we consider an IPv6 node located in the IPv6 Internet that initiates a communication to an IPv4 node located in the IPv4 site.
In some cases, this scenario can be addressed without using any form of DNS64 function. This is because it is possible to assign a fixed IPv6 address to each of the IPv4 nodes. Such an IPv6 address would be constructed using the address transformation algorithm defined in [RFC6052] that takes as input the Pref64::/96 and the IPv4 address of the IPv4 node. Note that the IPv4 address can be a public or a private address; the latter does not present any additional difficulty, since an NSP must be used as Pref64::/96 (in this scenario, the usage of the Well-Known Prefix is not supported as discussed in [RFC6052]). Once these IPv6 addresses have been assigned to represent the IPv4 nodes in the IPv6 Internet, real AAAA RRs containing these addresses can be published in the DNS under the site's domain. This is the recommended approach to handle this scenario, because it does not involve synthesizing AAAA records at the time of query.
However, there are some more dynamic scenarios, where synthesizing AAAA RRs in this setup may be needed. In particular, when DNS Update [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4 nodes, there are two options. One option is to modify the DNS server that receives the dynamic DNS updates. That would normally be the authoritative server for the zone. So the authoritative zone would have normal AAAA RRs that are synthesized as dynamic updates occur. The other option is to modify all of the authoritative servers to generate synthetic AAAA records for a zone, possibly based on additional constraints, upon the receipt of a DNS query for the AAAA RR. The first option -- in which the AAAA is synthesized when the DNS update message is received, and the data published in the relevant zone -- is recommended over the second option (i.e., the synthesis upon receipt of the AAAA DNS query). This is because it is usually easier to solve problems of misconfiguration when the DNS responses are not being generated dynamically. However, it may be the case where the primary server (that receives all the updates) cannot be upgraded for whatever reason, but where a secondary can be upgraded in order to handle the (comparatively small amount of) AAAA queries. In such a case, it is possible to use the DNS64 as described next. The DNS64 behavior that we describe in this section covers the case of synthesizing the AAAA RR when the DNS query arrives.
The scenario for this case is depicted in the following figure:
+-----------+ +----------------------+
| | | IPv4 site |
| IPv6 | +------------+ | +----+ |
| Internet |----| IPv6/IPv4 |--|---| H2 | |
| | | Translator | | +----+ |
| | +------------+ | |
| | | | 192.0.2.1 |
| | +------------+ | |
| |----| Name server|--| |
| | | with DNS64 | | |
+-----------+ +------------+ | |
| | | |
+----+ | |
| H1 | +----------------------+
+----+
Figure 6: "The IPv6 Internet to an IPv4 Network" Setup with DNS64 in DNS Server Mode
The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN h2.example.com.
The IPv6/IPv4 translator is using an NSP 2001:db8::/96 to create IPv6 representations of IPv4 addresses. The same prefix is configured in the DNS64 function in the local name server. The name server that implements the DNS64 function is the authoritative name server for the local domain.
The steps by which H1 establishes communication with H2 are:
-
H1 does a DNS lookup for h2.example.com. H1 does this by sending a DNS query for a AAAA record for H2. The query is eventually forwarded to the server in the IPv4 site.
-
The local DNS server resolves the query (locally), and discovers that there are no AAAA records for H2.
-
The name server verifies that h2.example.com and its A RR are among those that the local policy defines as allowed to generate a AAAA RR. If that is the case, the name server synthesizes a AAAA record from the A RR and the prefix 2001:db8::/96. The IPv6 address in the AAAA record is 2001:db8::192.0.2.1.
-
H1 receives the synthetic AAAA record and sends a packet towards H2. The packet is sent to the destination address 2001:db8:: 192.0.2.1.
-
The packet is routed through the IPv6 Internet to the IPv6 interface of the IPv6/IPv4 translator and the communication flows using the IPv6/IPv4 translator mechanisms.