With the depletion of the last top-level unicast IPv4 address prefixes in early in 2011, the embracing of IPv6 is beginning to accelerate. It was thought that hosts could be equipped with dual-stack functionality (i.e., each implements a complete IPv4 and IPv6 stack) [RFC4213] and network services would transition over to IPv6-only operation. It is now understood that IPv4 and IPv6 are likely to coex- ist for an extended period of time, perhaps indefinitely, and that for various eco- nomic reasons network infrastructure may operate using either IPv4 or IPv6 or both. Assuming that this is true, there will be an ongoing need to support com- munications between IPv4 and IPv6 systems, whether they are dual-stack or not.
The two major approaches that have been used to support combinations of IPv4 and IPv6 are tunneling and translation. The tunneling approaches include Teredo (see Chapter 10), Dual-Stack Lite (DS-Lite), and IPv6 Rapid Deployment (6rd).
Although DS-Lite involves SPNAT as part of its architecture, a purer translation approach is given by the framework described in [RFC6144], which uses the IPv4- embedded IPv6 addresses we saw in Chapter 2. We will discuss both DS-Lite and the translation framework in more detail in this section.
7.6.1 Dual-Stack Lite (DS-Lite)
DS-Lite [RFC6333] is an approach to make transition to IPv6 (and support for legacy IPv4 users) easier for service providers that wish to run IPv6 internally. In essence, it allows providers to focus on deploying an operational IPv6 core net- work yet provide IPv4 and IPv6 connectivity to their customers using a small num- ber of IPv4 addresses. The approach combines IPv4-in-IPv6 “softwire” tunneling [RFC5571] with SPNAT. Figure 7-16 shows the type of deployment envisioned.
ptg999
In Figure 7-16, each customer network operates with any combination of IPv4 and IPv6. The service provider’s network is assumed to be managed using only IPv6. Customer access to the IPv6 Internet is provided using conventional IPv6 routing. For IPv4 access, each customer uses a special “before” gateway (labeled
“B4” in Figure 7-16). A B4 element provides basic IPv4 services (e.g., DHCP service, a DNS proxy, etc.) but also encapsulates the customer’s IPv4 traffic in multi-point- to-point tunnels terminated at the “after” element (labeled “AFTR” in Figure 7-16).
The AFTR element performs decapsulation of traffic headed to the IPv4 Internet and encapsulation in the reverse direction. AFTR also performs NAT and acts as a form of SPNAT. More specifically, the AFTR may use the identity of the customer’s tunnel endpoint for disambiguating traffic returning to the AFTR from the IPv4 Internet. This allows multiple customers to use the same IPv4 address space. A B4 element can learn the name of its corresponding AFTR element using a DHCPv6 option called AFTR-Name [RFC6334].
It is instructive to recall the discussion of IPv6 rapid deployment (6rd) from Chapter 6. Whereas DS-Lite provides IPv4 access to customers over a service pro- vider’s IPv6 network, 6rd aims to provide IPv6 access to customers over a service provider’s IPv4 network. In essence, they take opposite approaches with similar architectural components. However, with 6rd, mapping from an IPv6 address to the address of the corresponding IPv4 tunnel endpoint (and vice versa) is com- puted in a stateless fashion using an address-mapping algorithm. Stateless address translation is also used in the framework for full protocol translation between IPv4 and IPv6, which we discuss next.
7.6.2 IPv4/IPv6 Translation Using NATs and ALGs
The biggest disadvantage of using tunneling techniques for supporting IPv4/IPv6 coexistence is that network services running on hosts using one address family
&XVWRPHUảV ,3 Y,3 Y
1HWZRUN
2WKHU3 DUWVRIWKH ,QWHUQHW
,3 Y
&XVWRPHUảV ,3 Y,3 Y
1HWZRUN
% $)75
% 6 HUYLFH 3 URYLGHUảV ,3 Y1HWZRUN
,3 YLQ,3 Y 7XQQHOV
2WKHU3 DUWVRIWKH ,QWHUQHW
,3 Y
,3 Y7UDIILF
Figure 7-16 DS-Lite allows service providers to support IPv4 and IPv6 customer networks using an IPv6-only infrastructure. IPv4 address usage is minimized by using SPNAT at the provider’s edge.
ptg999 Section 7.6 NAT for IPv4/IPv6 Coexistence and Transition 341
cannot be reached directly by the hosts using the other. Thus, an IPv6-only host can communicate only with other IPv6-capable systems. This is an undesirable sit- uation because many valuable services offered on the legacy IPv4 Internet would remain unavailable to new systems that may support only IPv6. To address this concern, a significant effort was undertaken between 2008 and 2010 to develop a framework to provide direct translation between IPv4 and IPv6. This effort was informed by poor experiences with NAT-PT [RFC2766], which was ultimately determined to be too brittle and unscalable for ongoing use and was deprecated [RFC4966].
The IPv4/IPv6 translation framework is given in [RFC6144]. The basic transla- tion architecture involves both stateful and stateless methods to convert between IPv4 and IPv6 addresses, translations for DNS (see Chapter 11), and the definition of any additional behaviors or ALGs in cases where they are necessary (including for ICMP and FTP). In this section, we will discuss the basics of the stateless and stateful address translation for IP based on [RFC6145], [RFC6146], and the address- ing from [RFC6052] we discussed in Chapter 2. Other protocol-specific translation issues will be covered in subsequent chapters.
7.6.2.1 IPv4-Converted and IPv4-Translatable Addresses
In Chapter 2, we discussed the structure of IPv4-embedded IPv6 addresses. Such addresses are IPv6 addresses that can be used as input to a function that produces a corresponding IPv4 address. The function is also easily inverted. There are two important types of IPv4-embedded IPv6 addresses, called IPv4-converted addresses and IPv4-translatable addresses. Each type of address mentioned is a subset of the other types. That is, if we treat each address category as a set, then (IPv4- translatable) ⊂ (IPv4-converted) ⊂ (IPv4-embedded) ⊂ (IPv6). IPv4-translatable addresses are IPv6 addresses for which an IPv4 address can be determined in a stateless fashion (see Section 7.6.2.2).
Algorithmic translation between IPv4 and IPv6 addresses involves the use of a prefix, as described in Chapter 2. The prefix may be either the Well-Known Pre- fix (WKP) 64:ff9b::/96 or another Network-Specific Prefix that is ordinarily owned by a service provider and used specifically with its translators. The WKP is used only in representing ordinary globally routable IPv4 addresses; private addresses [RFC1918] are not to be used with the WKP. In addition, the WKP is not to be used for creating IPv4-translatable addresses. Such addresses are intended to be defined within the scope of a provider’s network, so it is not appropriate to use them at a global scope.
The WKP is interesting because it is checksum-neutral with respect to the Inter- net checksum. Recall the Internet checksum calculation from Chapter 5. If we treat the prefix 64:ff9b::/96 as being composed of the hexadecimal values 0064, ff9b, 0000, 0000, 0000, 0000, 0000, 0000, the sum of these values is ffff, which is equal to 0 in one’s complement. Consequently, when an IPv4 address has the WKP pre- pended, the associated Internet checksums in packets created as a result of trans- lation (e.g., in the IPv4 header, TCP, or UDP checksum) are unaffected. Naturally, an appropriately chosen Network-Specific Prefix can also be checksum-neutral.
ptg999 In the following two subsections, we will use the notation To4(A6, P) to rep-
resent the IPv4 address derived from IPv6 address A6 in conjunction with prefix P. P is either the WKP or some Network-Specific Prefix. We will use the notation To6(A4, P) to represent the IPv6 address derived from IPv4 address A4 in conjunc- tion with prefix P. Note that, with a few special exceptions, A6 = To6(To4(A6,P),P) and A4 = To4(To6(A4,P),P).
7.6.2.2 Stateless Translation
Stateless IP/ICMP Translation (SIIT) refers to a method of translating between IPv4 and IPv6 packets without using state tables [RFC6145]. The translation is per- formed without table lookups and uses IPv4-translatable addresses along with a defined scheme to translate IP headers. For the most part, IPv4 options are not translated (they are ignored), nor are IPv6 extension headers (except the Frag- ment header). The exception is an unexpired IPv4 Source Route option. If such an option is present, the packet is dropped and a corresponding ICMP error message (Destination Unreachable, Source Route Failed; see Chapter 8) is generated. Table 7-5 describes how the IPv6 header fields are assigned when translating an IPv4 datagram to IPv6.
Table 7-5 Methods for creating an IPv6 header when translating IPv4 to IPv6
IPv6 Field Assignment Method
Version Set to 6.
DS Field/ECN Copied from same values in IPv4 header Flow Label Set to 0.
Payload Length Set to IPv4 Total Length minus length of the IPv4 header (including options).
Next Header Set to IPv4 Protocol field (or 58 if the Protocol field had value 1).
Set to value 44 to indicate a Fragment header if the IPv6 datagram being created is a fragment or DF bit not set.
Hop Limit Set to the IPv4 TTL field minus 1 (if this value is 0, the packet is discarded and an ICMP Time Exceeded message is generated; see Chapter 8).
Source IP Address Set to To6(IPv4 Source IP Address, P).
Destination IP Address
Set to To6(IPv4 Destination IP Address, P).
During the translation process, the IPv4 header is stripped and replaced with an IPv6 header. If the arriving IPv4 datagram is too large to fit in the MTU for the next link and the DF bit field in its header is not set, multiple IPv6 fragment packets may be produced, each containing a Fragment header. This also occurs when the arriving IPv4 datagram is a fragment. [RFC6145] recommends a Fragment header
ptg999 Section 7.6 NAT for IPv4/IPv6 Coexistence and Transition 343
be included in the resulting IPv6 datagram whenever the arriving IPv4 datagram’s DF bit field has value zero, whether or not the translator needs to perform frag- mentation or the arriving datagram is a fragment. This allows the IPv6 receiver to know that the IPv4 sender was likely not using PMTUD. When a Fragment header is included, its fields are set according to the methods listed in Table 7-6.
Table 7-6 Methods for assigning fields of the Fragment header, if used, during IPv4-to-IPv6 translation
Fragment Header Field Assignment Method Next Header Set to the IPv4 Protocol field.
Fragment Offset Copied from the IPv4 Fragment Offset field.
More Fragments Bit Copied from the IPv4 More Fragments (M) bit field.
Identification The low-order 16 bits are set from the IPv4 Identification field.
The high-order 16 bits are set to 0.
The reverse direction (IPv6-to-IPv4 translation) involves creating an IPv4 datagram with header field values based on fields in the arriving IPv6 header.
Obviously the much larger IPv6 address space does not allow an IPv4-only host to access every host on the IPv6 Internet. Table 7-7 gives the methods used to assign the fields in the outgoing IPv4 datagram’s header when an unfragmented IPv6 datagram arrives.
Table 7-7 Methods for creating an IPv4 header when translating unfragmented IPv6 to IPv4 IPv4 Header Field Assignment Method
Version Set to 4.
IHL Set to 5 (no IPv4 options).
DS Field/ECN Copied from same values in IPv6 header.
Total Length The value of the IPv6 Payload Length field plus 20.
Identification Set to 0 (with option to set to some other predetermined value).
Flags More Fragments (M) is set to 0. Don’t Fragment (DF) is set to 1.
Fragment Offset Set to 0.
TTL The value of the IPv6 Hop Limit field minus 1 (must be at least 1).
Protocol Copied from the first IPv6 Next Header field that does not refer to a Fragment header, HOPOPT, IPv6-Route, or IPv6-Opts.
Value 58 is changed to 1 to support ICMP (see Chapter 8).
Header Checksum Computed for the newly created IPv4 header.
Source IP Address To4(IPv6 Source IP Address, P).
Destination IP Address To4(IPv6 Destination IP Address, P).
ptg999 If the arriving IPv6 datagram includes a Fragment header, the outgoing IPv4
datagram uses field values based on assignment methods modified from those in Table 7-7. Table 7-8 gives this case.
Table 7-8 Methods for creating an IPv4 header when translating fragmented IPv6 to IPv4
IPv4 Header Field Assignment Method
Total Length The value of the IPv6 Payload Length field minus 8 plus 20.
Identification Copied from the low-order 16 bits in the Identification field of the IPv6 Fragment header.
Flags More Fragments (M) copied from the M bit field in the IPv6 Fragment header. Don’t Fragment (DF) is set to 0 to allow fragmentation in the IPv4 network.
Fragment Offset Copied from the Fragment Offset field of the IPv6 Fragment header.
In the case of fragmented IPv6 datagrams, the translator produces fragmented IPv4 datagrams. Note that in IPv6 the Identification field is larger, so there is a pos- sibility that certain fragments could fail to be reassembled properly if multiple distinct IPv6 datagrams from the same host are fragmented in such a way that the Identification field values they use share a common lower-order 16 bits. However, this situation is no more risky than having the conventional IPv4 Identification field wrap. Furthermore, integrity checks at higher layers make this issue nothing much to worry about.
7.6.2.3 Stateful Translation
In stateful translation, NAT64 [RFC6146] is used to support IPv6-only clients com- municating with IPv4 servers. This is expected to be important during the period when many important services continue to be offered using only IPv4. The trans- lation method for headers is nearly identical to the methods described for stateless translation in Section 7.6.2.2. As a NAT, NAT64 complies with BEHAVE specifica- tions and supports only endpoint-independent mappings, along with both end- point-independent and address-dependent filtering. Thus, it is compatible with the NAT traversal techniques (e.g., ICE, STUN, TURN) we discussed previously.
Lacking these additional protocols, NAT64 supports dynamic translation only for IPv6 hosts initiating communications with IPv4 hosts.
NAT64 works much like conventional NAT (NAPT) across address families, except translations in the IPv4-to-IPv6 direction are simpler than in the reverse direction. A NAT64 device is assigned an IPv6 prefix, which can be used to form a valid IPv6 address directly from an IPv4 address using the mechanism described in Chapter 2 and [RFC6052]. Because of the comparative scarcity of the IPv4 address space, translations in the IPv6-to-IPv4 direction make use of a pool of IPv4 addresses that are ordinarily managed dynamically. This requires NAT64 to support NAPT functionality, whereby multiple distinct IPv6 addresses may map
ptg999 Section 7.7 Attacks Involving Firewalls and NATs 345
to the same IPv4 address. NAT64 currently defines methods for translation of TCP, UDP, and ICMP messages initiated by IPv6 nodes. (In the case of ICMP queries and responses, the ICMP Identifier field is used instead of the transport-layer port number; see Chapter 8.)
NAT64 handles fragments differently from its stateful counterpart. For arriv- ing TCP or UDP fragments where the transport checksum is nonzero (see Chapter 10), the NAT64 may either queue the fragments and translate them together or translate them individually. A NAT64 must handle fragments, even those arriving out of order. A NAT64 may be configured with a time limit (at least 2s) bounding the time during which fragments will be cached. Otherwise, the NAT could be subject to a DoS attack resulting from the exhaustion of packet buffers holding fragments.