IPv6 to IPv4 translation

+--[IPv6]-----------------------+      +--[IPv4]----------+
| SRC 2001:db8:12:34::1         |      | SRC 192.0.2.1    |
| DST 2001:db8:46::203.0.113.50 | -->  | DST 203.0.113.50 |
| TCP SYN/ACK [..]              |      | TCP SYN/ACK [..] |
+-------------------------------+      +------------------+
          

Figure 3

It is important to note that neither the IPv4 client nor the IPv6 server/application need any special support to participate in SIIT-DC. However, the application may optionally be taught to extract the embedded IPv4 source address from incoming IPv6 packets with source addresses within the Translation Prefix. This will allow it to perform IPv4-specific tasks such as Geo-Location, logging, abuse handling, and so on.

4. Deployment Considerations and Guidelines

4.1. Application/Device Support for IPv6

SIIT-DC as described in this document requires that the application (and/or the node the application is located on) supports IPv6 networking, and that it has no dependency on local IPv4 network connectivity.

SIIT-DC can however support legacy IPv4-dependent applications and nodes through the introduction of an ER. The ER provides the legacy application or node with seemingly native IPv4 Internet connectivity, so that it may operate correctly in an otherwise IPv6-only network environment. This approach is described in more detail in [I-D.ietf-v6ops-siit-dc-2xlat].

4.2. Application Support for NAT

The operator should carefully examine whether or not the application protocols he would like to use SIIT-DC with are able to operate in a network environment where rewriting of IP addresses occur. In general, if an application layer protocol works correctly through standard NAT44 (see [RFC3235]), it will most likely work correctly through SIIT-DC as well.

Higher-level protocols that embed IP addresses as part of their payload are particularly problematic [RFC2663] [RFC2993] [RFC3022]. One well-known example of such a protocol is FTP [RFC0959]. Such protocols can be made to work with SIIT-DC through the introduction of an ER, which provides end-to-end IPv4 address transparency by reversing the translations performed by the BR before passing the packets to the NAT-incompatible application. This approach is described in more detail in [I-D.ietf-v6ops-siit-dc-2xlat].

4.3. Application Communication Pattern

SIIT-DC is best suited for traditional client/server applications where IPv4-only clients on the Internet initiate traffic towards an IPv6-only service, which in turn is passively listening for inbound traffic and responding as necessary. In this case, an IPv4 client looks exactly like an native IPv6 client from the IPv6 service's point of view, and thus does not require any special treatment. One particularly common application protocol that follows this client/server communication pattern, and thus is ideally suited for use with SIIT-DC, is HTTP [RFC7230].

It is also possible to combine SIIT-DC with DNS64 [RFC6147] in order to allow an IPv6-only application to initiate communication with IPv4-only nodes through SIIT-DC. However, in this case, care must be taken so that all outgoing communication is sourced from an IPv6 Service Address that is found in an EAM configured in the BR. If another address is used, the BR will most likely be unable to translate it to IPv4, causing the packet to be discarded. This could be prevented by altering the Default Address Selection Policy Table [RFC6724] on the IPv6 node.

An alternative approach to the above would be to place an ER in front of the application in question, as described [I-D.ietf-v6ops-siit-dc-2xlat]. This provides the application with seemingly native IPv4 connectivity, which it may use freely for bi-directional communication with the IPv4 Internet. An application or node located behind an ER does not need to worry about selecting a specific source address, as it will only have valid options available.

4.4. Choice of Translation Prefix

Either a Network-Specific Prefix (NSP) from the provider's own IPv6 address space or the IANA-allocated Well-Known Prefix 64:ff9b::/96 (WKP) may be used. From a technical point of view, both work equally well. However, only a single WKP exists, so if a provider would like to deploy more than one instance of SIIT-DC in his network, or another translation technology such as Stateful NAT64 [RFC6146], the operator will be forced to use an NSP for all but one of those deployments.

Another consideration is that the WKP cannot be used in inter-domain routing. By using an NSP instead, SIIT-DC will support a deployment where the BR and the IPv6 Service Address are located in different Autonomous Systems.

The Translation Prefix may use any of the lengths described in Section 2.2 of [RFC6052], but /96 has two distinct advantages over the others. First, converting it to IPv4 can be done in a single operation by simply stripping off the first 96 bits; second, it allows for IPv4 addresses to be embedded directly into the text representation of an IPv6 address using the familiar dotted quad notation, e.g., "2001:db8::198.51.100.10" (cf. Section 2.4 of [RFC6052])), instead of being converted to hexadecimal notation. This makes it easier to write IPv6 ACLs and similar that match translated endpoints in the IPv4 Internet.

For the reasons discussed above, this document recommends that an NSP with a prefix length of /96 is used. Section 3.3 of [RFC6052] discusses the choice of translation prefix in more detail.

4.5. Routing Considerations

The prefixes that constitute the IPv4 Service Address Pool and the IPv6 Translation Prefix may be routed to the BRs as any other IPv4 or IPv6 route in the provider's network. If more than one BR is being deployed, it is recommended that a routing protocol (IGP) used to advertise the routes within the provider's network. This will ensure that the traffic that is to be translated will reach the closest BR, reducing or eliminating sub-optimal traffic patterns, as well as providing high availability: Should one BR fail, the IGP will automatically redirect the traffic to the closest alternate BR.

4.6. Location of the SIIT-DC Border Relays

The goal of SIIT-DC is to facilitate a true IPv6-only application and network architecture, with the sole exception being the IPv4 interfaces of the BRs and the network infrastructure required to connect the BRs to the IPv4 Internet. Therefore, the BRs must be located somewhere between the IPv4 Internet and the application delivery stack - which includes all servers, load balancers, firewalls, intrusion detection systems, and similar devices that are processing traffic to a greater extent than merely forwarding it.

It is optimal to place the BRs as close as possible to the direct path between the location of the IPv6 Service Address and the end users. If the closest BR was located a long way from the direct path, all packets in both directions must make a detour in order to traverse the BR. This would increase the RTT between the service and the end user by by two times the extra latency incurred by the detour, as well as cause unnecessary load on the network links on the detour path.

Where possible, it is beneficial to implement the BRs as a logical function within the routers would have handled the traffic anyway, had the topology been dual stacked. This way, a SIIT-DC deployment does not require separate networks ports (which might become saturated and impact the service quality), nor will it require extra rack space and energy. Some particularly good choices of the location could be within an IDC's access routers, or within the Autonomous System's border routers.

Finally, another possibility is that the IDC operator outsources the SIIT-DC service to another entity, for example his upstream ISP. Doing so allows the IDC operator to build a true IPv6-only infrastructure.

4.7. Migration from Dual Stack

While this document mainly discusses the use of IPv6-only nodes and applications, it is important to note that SIIT-DC is fully compatible with dual stack infrastructures, including dual stack nodes and applications.

Thus, migrating a dual-stacked service to an IPv6-only one where SIIT-DC provides the IPv4 Internet connectivity is easy. The operator would start out by designating the service's current native IPv6 address as the IPv6 Service Address, and assign it a corresponding IPv4 Service Address. At this point, the service will respond on both its old (native) IPv4 address, and the SIIT-DC IPv4 Service Address. The operator may now move traffic from the former to the latter by changing the service's "IN A" DNS record. Once all IPv4 traffic has been successfully moved to SIIT-DC, the old IPv4 address may be reclaimed.

4.8. Translation of ICMPv6 Errors to IPv4

In response to an IPv4 packet subsequently translated to IPv6 by the BR, an IPv6 router in the IDC network may need to transmit an ICMPv6 error back to the origin IPv4 node. By default, such an ICMPv6 error will most likely be discarded by the BR, unless the source address of the ICMPv6 error happens to be a IPv4-translatable IPv6 address or covered by an EAM.

To facilitate reliable delivery of such ICMPv6 errors, an SIIT-DC operator SHOULD implement the recommendations in [RFC6791] in the BRs.

4.9. MTU and Fragmentation

There are some key differences between IPv4 and IPv6 relating to packet sizes and fragmentation that one MUST consider when deploying SIIT-DC. They result in a few problematic corner cases, which can be dealt with in a few different ways. The following subsections will discuss these in detail, and provide operational guidance.

In particular, the operator may find that relying on fragmentation in the IPv6 domain is undesired or even operationally impossible [I-D.taylor-v6ops-fragdrop]. For this reason, the recommendations in this section seeks to minimise the use of IPv6 fragmentation.

Unless otherwise stated, the following subsections assume that the MTU in both the IPv4 and IPv6 domains is 1500 bytes.

4.9.1. IPv4/IPv6 Header Size Difference

The IPv6 header is up to 20 bytes larger than the IPv4 header. This means that a full-size 1500 bytes large IPv4 packet cannot be translated to IPv6 without being fragmented, otherwise it would likely have resulted in a 1520 bytes large IPv6 packet.

If the transport protocol used is TCP, this is generally not a problem, the IPv6 node will advertise a TCP MSS of 1440 bytes during the initial TCP handshake. This causes the IPv4 clients to never send larger packets than what can be translated to a single full-size IPv6 packet, eliminating any need for fragmentation.

For other transport protocols, full-size IPv4 packets with the DF flag cleared will need to be fragmented by the BR. This may be avoided by increasing the Path MTU between the BR and the IPv6 nodes to 1520 bytes or greater. If this is done, the MTU on the IPv6 nodes themselves SHOULD NOT be increased accordingly, as doing so would cause them to undergo Path MTU Discovery for all destinations on the IPv6 Internet. The nodes MUST however be able to accept and process incoming packets larger than their own MTU. If the nodes' IPv6 implementation allows the initial Path MTU to be set differently for specific destinations, it MAY be increased to 1520 for destinations within the Translation Prefix specifically.

4.9.2. IPv6 Atomic Fragments

In keeping with the fifth paragraph of Section 4 of [RFC6145], a stateless translator like a BR will by default add an IPv6 Fragmentation header to the resulting IPv6 packet when translating an IPv4 packet with the Don't Fragment flag set to 0. This happens even though the resulting IPv6 packet isn't actually fragmented into several pieces, resulting in an IPv6 Atomic Fragment [RFC6946]. These Atomic Fragments are generally not useful in an IDC environment, and it is therefore recommended that this behaviour is disabled in the BRs. To this end, Section 4 of [RFC6145] notes that the "translator MAY provide a configuration function that allows the translator not to include the Fragment Header for the non-fragmented IPv6 packets".

Note that IPv6 Atomic Fragments are currently being deprecated by RFC6145bis [I-D.bao-v6ops-rfc6145bis]. As a result, a BR that conforms to the updated standard is required to behave as recommended above.

In IPv6, the Identification value is located inside the Fragmentation header. That means that if the generation of IPv6 Atomic Fragments is disabled, the IPv4 Identification value will be lost during translation to IPv6. This could potentially confuse some diagnostic tools.

4.9.3. Minimum Path MTU Difference Between IPv4 and IPv6

Section 5 of [RFC2460] specifies that the minimum IPv6 link MTU is 1280 bytes. Therefore, an IPv6 node can reasonably assume that if it transmits an IPv6 packet that is 1280 bytes or smaller, it is guaranteed to reach its destination without requiring fragmentation or invoking the Path MTU Discovery algorithm [RFC1981]. However, this assumption might prove false if the destination is an IPv4 node reached through a protocol translator such as a BR, as the minimum IPv4 link MTU is 68 bytes. See Section 3.2 of [RFC0791].

Section 5.1 of [RFC6145] specifies that a stateless translator should set the IPv4 Don't Fragment flag to 1 when it translates a non-fragmented IPv6 packet to IPv4. This means that when the path to the destination IPv4 node contains an IPv4 link with an MTU smaller than 1260 bytes (which corresponds to an IPv6 MTU smaller than 1280 bytes, cf. Section 4.9.1), the Path MTU Discovery algorithm will be invoked, even if the original IPv6 packet was only 1280 bytes large. This happens as a result of the IPv4 router connecting to the IPv4 link with the small MTU returning an ICMPv4 Need To Fragment error with an MTU value smaller than 1260, which in turns is translated by the BR to an ICMPv6 Packet Too Big error with an MTU value smaller than 1280 which is then transmitted to the origin IPv6 node.

When an IPv6 node receives an ICMPv6 Packet Too Big error indicating an MTU value smaller than 1280, the last paragraph of Section 5 of [RFC2460] gives it two choices on how to proceed:

• It may reduce its Path MTU value to the value indicated in the Packet Too Big, i.e., limit the size of subsequent packets transmitted to that destination to the indicated value. This approach causes no problems for the SIIT-DC function, as it simply allows Path MTU Discovery to work transparently across the BR.
• It may reduce its Path MTU value to exactly 1280, and in addition include a Fragmentation header in subsequent packets sent to that destination. In other words, the IPv6 node will start emitting Atomic Fragments. The Fragmentation header signals to the the BR that the Don't Fragment flag should be set to 0 in the resulting IPv4 packet, and it also provides the Identification value.

If the use of the IPv6 Fragmentation header is problematic, and the operator has IPv6 nodes that implement the second option above, the operator should consider enabling the functionality described as the "second approach" in Section 6 of [RFC6145]. This functionality changes the BR's behaviour as follows:

• When translating ICMPv4 Need To Fragment to ICMPv6 Packet Too Big, the resulting packet will never contain an MTU value lower than 1280. This prevents the IPv6 nodes from generating Atomic Fragments.
• When translating IPv6 packets smaller than or equal to 1280 bytes, the Don't Fragment flag in the resulting IPv4 packet will be set to 0. This ensures that in the eventuality that the path contains an IPv4 link with an MTU smaller than 1260, the IPv4 router connected to that link will have the responsibility to fragment the packet before forwarding it towards its destination.

In summary, this approach could be seen as prompting the IPv4 protocol itself to provide the "link-specific fragmentation and reassembly at a layer below IPv6" required for links that "cannot convey a 1280-octet packet in one piece", to paraphrase Section 5 of [RFC2460].

Note that IPv6 Atomic Fragments are currently being deprecated by RFC6145bis [I-D.bao-v6ops-rfc6145bis]. As a result, a BR that conforms to the updated standard is required to behave as suggested above.

4.10. IPv4-translatable IPv6 Service Addresses

SIIT-DC is designed so that the IPv6 Service Addresses are not required to be IPv4-translatable IPv6 addresses. Section 2 of [I-D.ietf-v6ops-siit-eam] discusses why it is desirable to avoid requiring the use of IPv4-translatable IPv6 addresses.

It is however quite possible to deploy SIIT-DC in combination with IPv4-translatable IPv6 Service Addresses. The primary benefits in doing so are:

• The operator is not required to provision EAMs for IPv4-translatable IPv6 Service Addresses onto the BR/ERs.
• [RFC6145] translation can be performed in a checksum-neutral manner, cf. Section 4.1 of [RFC6052].

The trade-off is that the IPv4-translatable IPv6 Service Addresses must be configured on the IPv6 nodes, and the applications must be set up to use them - likely in addition to their primary (non-IPv4-translatable) IPv6 addresses. The IPv4-translatable IPv6 Service Addresses must also be routed from the BR through the IDC's IPv6 network infrastructure to the nodes on which they are assigned. This essentially requires the entire IPv6 infrastructure to be made aware of and handle translated IPv4 traffic as a special case, which significantly increases complexity. As previously described in Section 1.1, avoiding such drawbacks is a design goal of SIIT-DC. The use of IPv4-translatable IPv6 Service Addresses is therefore discouraged.

5. Acknowledgements

The author would like to thank the following individuals for their contributions, suggestions, corrections, and criticisms: Fred Baker, Cameron Byrne, Brian E Carpenter, Ross Chandler, Tobias Gondrom, Christer Holmberg, Dagfinn Ilmari Mannsaaker, Lars Olafsen, Stig Sandbeck Mathisen, Knut A. Syed, Qin Wu, Andrew Yourtchenko.

6. IANA Considerations

This draft makes no request of the IANA.

7. Security Considerations

7.1. Mistaking the Translation Prefix for a Trusted Network

If a Network-Specific Prefix from the provider's own address space is chosen for the translation prefix, as recommended in Section 4.4, care MUST be taken if the translation service is used in front of services that have application-level ACLs that distinguish between the operator's own networks and the Internet at large, as traffic from translated IPv4 end users on the Internet might appear to be originating from the provider's own network. It is therefore important that the translation prefix is treated the same as the Internet at large, rather than as a trusted network.

In order to alleviate this problem, the operator may opt to use a Translation Prefix that is distinct from and not a subset of the IPv6 prefixes used elsewhere in the network infrastructure.

8. References

8.1. Normative References

8.2. Informative References

Appendix A. Complete SIIT-DC IDC topology example

Figure 4 attempts to "tie it all together" and show a more complete SIIT-DC topology, in order to better demonstrate its advantageous properties discussed in Section 1. These are discussed in more detail below.

             /--------------------------------\ /---------------\
             |          IPv4 Internet         | | IPv6 Internet |
             \-+----------------------------+-/ \--------+------/
               |                            |            |
               | <----------[BGP]---------> |          [BGP]
               |                            |            |
+-------<192.0.2.0/24>---------+ +---<192.0.2.0/24>---+  |
|                        BR #1 | | BR #2              |  |
| EAM Table:                   | |                    |  |
| ==========                   | |                    |  |
| 192.0.2.1,2001:db8:12:34::1  | |                    |  |
| 192.0.2.2,2001:db8:12:34::2  | |  Exactly the same  |  |
| 192.0.2.3,2001:db8:fe:dc::1  | |  configuration as  |  |
| 192.0.2.4,2001:db8:12:34::4  | |  BR #1 has         |  |
| 192.0.2.5,2001:db8:fe:dc::e  | |                    |  |
|                              | |                    |  |
| XLAT Prefix 2001:db8:46::/96 | |                    |  |
|                              | |                    |  |
+--------<2001:db8:46::/96>----+ +-<2001:db8:46::/96>-+  |
                  |                      |               |
                  | <------[ECMP]------> |               |
                  |                      |               |
/-----------------+----------------------+--\            |
|         IPv6 IDC network w/OSPFv3         +------------/
\-+--------------------------------+--------/
  |                                |
  | Tenant A's server LAN          | Tenant B's server LAN
  | 2001:db8:12:34::/64            | 2001:db8:fe:dc::/64
  |                                |
  +-- www      ::1 (IPv6+SIIT-DC)  +-- www-lb ::1 (IPv6+SIIT-DC)
  |                                |
  +-- mta      ::2 (IPv6+SIIT-DC)  +-- web ::80:01 (IPv6-only)
  |                                |   [...]
  +-- ftp      ::3 (IPv6)          +-- web ::80:99 (IPv6-only)
  |            ::4 (IPv4, via ER)  |
  |                                |         +----+
  +-- app01 ::a:01 (IPv6-only)     \---- ::e | ER | --\
  |   [...]                                  +----+   |
  +-  app99 ::a:99 (IPv6-only)                        |
  |                                  ftp 192.0.2.5 ---/
  +-- db01  ::d:01 (IPv6-only)
  |   [..]
  \-- db99  ::d:99 (IPv6-only)