Stage 4: Server -> Client response, IPv4

+------------------------------------------------+
| IP Version:           4                        |
| Source Address:       192.0.2.2                |
| Destination Address:  203.0.113.50             |
| Protocol:             TCP                      |
|------------------------------------------------|
| TCP SYN+ACK [...]                              |
+------------------------------------------------+
          

Figure 6

This time, the source address matched the Static Address Mapping and was translated accordingly, while the destination address did not, and was therefore translated according to [RFC6052] by having the Translation Prefix stripped. The rest of the packet was translated according to [RFC6145].

The resulting IPv4 packet is transmitted back to the end user over the IPv4 Internet. Subsequent packets in the flow will follow the exact same translation pattern. They may or may not cross the same translators as earlier packets in the same flow.

The end user's IPv4 stack has no idea that it is communicating with an IPv6 server, nor does the server's IPv6 stack have any idea that is is communicating with an IPv4 client. To them, it's just plain IPv4 or IPv6, respectively. However, the applications running on the server may optionally be updated to recognise and strip the Translation Prefix, so that the end user's IPv4 address may be used for logging, Geo-Location, abuse handling, and so forth.

4. Deployment Guidelines

In this section, we list recommendations and guidelines for operators who would like to deploy a SIIT-DC service in their data centre network.

4.1. Application Support for NAT

Not all application protocols are able to operate in a network environment where rewriting of IP addresses occur. An operator should therefore carefully evaluate the applications he would like to make available for IPv4 users through SIIT-DC, to ensure they do not fall in this category. 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 especially problematic, as noted in [RFC2663], [RFC2993], and [RFC3022]. Such protocols will most likely not work through any form of address translation, including SIIT-DC. One well-known example of such a protocol is FTP [RFC0959].

The SIIT-DC architecture may be extended with a Host Agent that reverses the translation performed by the SIIT-DC Gateway before passing the packets to the application software. This allows the problematic application protocols described above to work correctly in an SIIT-DC environment as well. See [I-D.anderson-v6ops-siit-dc-2xlat] for a description of this extension.

4.2. Application Support for IPv6

SIIT-DC requires that the application software supports IPv6 networking, and that it has no dependency on IPv4 networking. If this is not the case, the approach described in [I-D.anderson-v6ops-siit-dc-2xlat] may be used, as it provides the application with seemingly native IPv4 connectivity. This allows IPv4-only applications to work correctly in an otherwise IPv6-only environment.

4.3. Application Communication Pattern

SIIT-DC is ideally suited for applications where IPv4-only nodes on the Internet initiate traffic towards the IPv6-only services, which in turn are only passively listening for inbound traffic and responding as necessary. One well-known example of such a protocol is HTTP [RFC2616]. This is due to the fact that in this case, an IPv4 user looks exactly like an ordinary IPv6 user from the host and application's point of view, and requires no special treatment.

It is possible to combine SIIT-DC with DNS64 [RFC6147] in order to allow an IPv6-only application to initiate communication with IPv4-only nodes through an SIIT-DC Gateway. However, in this case, care must be taken so that all outgoing communication is sourced from the IPv6 Service Address that has a Static Mapping configured on the SIIT-DC Gateway. If another unmapped address is used, the SIIT-DC Gateway will discard the packet.

An alternative approach to the above would be to make use of an SIIT-DC Host Agent as described in [I-D.anderson-v6ops-siit-dc-2xlat]. This provides the application with seemingly native IPv4 connectivity, which it may use for both inbound and outbound communication without requiring the application to select a specific source address for its outbound communications.

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 should work equally well, however as only a single WKP exists, if a provider would like to deploy more than one instance of SIIT-DC in his network, or Stateful NAT64 [RFC6146], an NSP must be used anyway for all but one of those deployments.

Furthermore, the WKP cannot be used in inter-domain routing. By using an NSP, a provider will have the possibility to provide SIIT-DC service to other operators across Autonomous System borders.

For these reasons, this document recommends that an NSP is used. Section 3.3 of [RFC6052] discusses the choice of translation prefix in more detail.

The Translation Prefix may use any of the lengths described in Section 2.2 of RFC6052 [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 [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. Use of a /96 prefix length is therefore recommended.

4.5. Routing Considerations

The prefixes that constitute the IPv4 Service Address Pool and the IPv6 Translation Prefix may be routed to the SIIT-DC Gateway(s) as any other IPv4 or IPv6 route in the provider's network.

If more than one SIIT-DC Gateway is being deployed, it is recommended that a dynamic routing protocol (such as BGP, IS-IS, or OSPF) is being 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 SIIT-DC Gateway, reducing or eliminating sub-optimal traffic patterns, as well as provide high availability - if one SIIT-DC Gateway fails, the dynamic routing protocol will automatically redirect the traffic to the next-best translator.

4.6. Location of the SIIT-DC Gateways

It is optimal to place the SIIT-DC Gateways as close as possible to the direct path between the servers and the end users. If the closest translator is located a long way from the optimal path, all packets in both directions must make a detour. This would increase the RTT between the server 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.

The ideal location of the SIIT-DC Gateways would be a logical function within the IP routers would have handled the traffic anyway (if the topology was dual stacked) This way, the translation service would not need separate networks ports to be assigned (which might become saturated and impact the service quality), nor would it need extra rack space or energy. Some good choices of the location could be within a data centre's access routers, or inside the provider's border routers. If every single application in the data centre or the provider's network eventually get single-stacked, there would no need to run IPv4 on the inside of the SIIT-DC Gateway - thus allowing the operator to reclaim IPv4 addresses from the network infrastructure that may instead be used for translated services.

4.7. Migration from Dual Stack

While this document discusses the use of IPv6-only servers and applications, there is no technical requirement that the servers are IPv4 free. SIIT-DC works equally well for dual stacked servers, which makes migration easy - after setting up the translation function, the DNS A record for the service is updated to point to the IPv4 address that will be translated to IPv6, the previously used IPv4 service address may continue to be assigned to the server. This makes roll-back to dual stack easy, as it is only a matter of changing the DNS record back to what it was before.

For high-volume services migrating to SIIT-DC from dual stack, DNS Round Robin may be used to gradually migrate the service's IPv4 traffic from its native IPv4 address(es) to the translated IPv4 Service Address(s).

4.8. Packet Size and Fragmentation Considerations

There are two key differences between IPv4 and IPv6 relating to packet sizes that one should consider when deploying SIIT-DC. They result in a few problematic corner cases, which can be dealt with in a few different ways.

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, this section assumes that the MTU in both the IPv4 and IPv6 domains is 1500 bytes.

4.8.1. IP 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, as the IPv6 server will advertise a TCP MSS of 1440 bytes. This causes the client 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 SIIT-DC Gateway. The only way to avoid this is to increase the Path MTU between the SIIT-DC Gateway and the servers to 1520 bytes. Note that the servers' MTU SHOULD NOT be increased accordingly, as that would cause them to undergo Path MTU Discovery for most native IPv6 destinations. However, the servers would need to be able to accept and process incoming packets larger than their own MTU. If the server's IPv6 implementation allows the MTU to be set differently for specific destinations, it could be increased to 1520 for destinations within the Translation Prefix specifically.

4.8.2. Minimum Path MTU Difference

The minimum allowed link MTU in IPv6 is 1280 bytes. In IPv4, the corresponding value is 68 bytes. This means that an 1280 byte large IPv6 packet sent to an IPv4 client may need to be fragmented by a router in the IPv4 network, if the path to the IPv4 client involves a link with a MTU lower than 1260 bytes.

By default, an SIIT-DC Gateway will set the DF flag when translating from IPv6 to IPv4, resulting in a situation where the IPv6 server may receive an ICMPv6 Packet Too Big error where the indicated MTU value is less than the IPv6 minimum of 1280. In this situation, the IPv6 server has two choices on how to proceed, according to the last paragraph of Section 5 of RFC2460 [RFC2460]:

• It may reduce its Path MTU value to the value indicated in the Packet Too Big. This causes no problems for the SIIT-DC function.
• It may reduce its Path MTU value to exactly 1280, and also include a Fragmentation header in each subsequent packet sent to that destination. The Fragmentation header signals to the the SIIT-DC Gateway that the DF flag should be cleared 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 servers that implement the second option above, the operator should enable a feature on the SIIT-DC Gateways which ensures that the resulting MTU field is always set to 1280 or higher when translating ICMPv4 Need to Fragment into ICMPv6 Packet Too Big, and that when translating IPv6 packets smaller or equal to 1280 bytes the resulting IPv4 packets will have the DF flag cleared and an Identification value generated, cf. Section 5.5.

4.8.3. "Atomic Fragments"

By default, an SIIT-DC Gateway will include a Fragmentation header in the resulting IPv6 packet when translating from an IPv4 packet with the DF flag cleared, cf. Section 4 of RFC6145 [RFC6145].

This happens even though the resulting IPv6 packet isn't actually fragmented into several pieces, resulting in an "Atomic Fragment" [RFC6946]. This is generally not useful in a data centre environment, and it is therefore recommended that this behaviour is disabled in the SIIT-DC Gateway(s). See Section 5.4.

5. Implementation Requirements

This normative section specifies the SIIT-DC protocol that is implemented by an SIIT Gateway. Because SIIT-DC builds on and closely resembles SIIT [RFC6145], this section should be read as a set of additions and changes that are applied to an implementation already compliant to SIIT [RFC6145]. Each of the following subsections discuss how the requirement relates to with any corresponding requirements in SIIT [RFC6145].

5.1. Compliance with RFC6145 and RFC6052

Unless otherwise stated in the following sections, an SIIT-DC implementation MUST comply fully with [RFC6145]. It must also implement the algorithmic address mapping defined in [RFC6052].

5.2. Static Address Mapping Function

The implementation MUST allow the operator to configure an arbitrary number of Static Address Mappings which override the default [RFC6052] algorithm. It SHOULD be possible to specify a single bi-directional mapping that will be used in both the IPv4=>IPv6 and IPv6=>IPv4 directions, but it MAY additionally (or alternatively) support unidirectional mappings.

An example of such a bidirectional Static Address Mapping would be:

• 192.0.2.1 <=> 2001:db8:12:34::1

To accomplish the same using unidirectional mappings, the following two mappings must instead be configured:

• 192.0.2.1 => 2001:db8:12:34::1
• 2001:db8:12:34::1 => 192.0.2.1

In both cases, if the SIIT-DC Gateway receives an IPv6 packet that has the value 2001:db8:12:34::1 in either the source or destination field of the IPv6 header, it MUST rewrite this field to 192 0.2.1 when translating to IPv4. Similarly, if the SIIT-DC Gateway receives an IPv4 packet that has the value 192.0.2.1 as the either the source or destination field of the IPv4 header, it MUST rewrite this field to 2001:db8:12:34::1 when translating to IPv6. For all IPv4 or IPv6 source or destination field values for which there are no Static Address Mapping, [RFC6052] compliant mapping MUST be used instead.

Relation to [RFC6145]: The Static Address Mapping is a novel feature feature that is not discussed in [RFC6145]. It conflicts with [RFC6145]'s requirement that all addresses must be translated according to the [RFC6052] algorithm.

5.3. Support for Increasing the IPv6 Path MTU

The SIIT-DC Gateway MUST provide a configuration function for the network administrator to adjust the threshold of the minimum IPv6 MTU to a value that reflects the real value of the minimum IPv6 MTU in the network (greater than 1280 bytes). This will help reduce the chance of including the Fragment Header in the packets.

Relation to [RFC6145]: This strengthens the corresponding "MAY" requirement located in Section 4 of RFC6145 [RFC6145] to a "MUST".

5.4. Support for Disabling "Atomic Fragments"

When the IPv4 sender does not set the DF bit, the SIIT-DC Gateway SHOULD NOT include an IPv6 Fragment Header in resulting non-fragmented IPv6 packets. If does, the SIIT-DC Gateway MUST provide a configuration function that allows the SIIT-DC Gateway not to include the Fragment Header for the non-fragmented IPv6 packets.

Relation to [RFC6145]: This is an update of the corresponding requirement in Section 4 of RFC6145 [RFC6145]. It inverts the recommended default behaviour to not generate IPv6 Atomic Fragments, and strengthens the "MAY" requirement for making it possible to disable this behaviour to a "MUST".

For the definition of an "Atomic Fragment", see [RFC6946].

5.5. Feature for Handling IPv4 Path MTUs Lower than 1260

In order to prevent unnecessary fragments, the implementation SHOULD support a feature which, if enabled by the operator, changes the SIIT-DC Gateway's default behaviour accordingly:

• When translating an ICMPv4 Need To Fragment packet indicating a Path MTU smaller than or equal to 1260, the MTU field in the resulting ICMPv6 Packet Too Big is set to 1280.
• When translating an IPv6 packet that is smaller or equal to 1280 bytes, the DF flag in the resulting IPv4 packet is cleared, and an IPv4 Identification value is generated. The SIIT-DC Gateway MUST NOT create or maintain any state as a result of this.

Relation to [RFC6145]: This is a modified version of the second approach described in Section 6 of RFC6145 [RFC6145]. The modifications are:

1. In the IPv4-to-IPv6 direction, the algorithm only used for ICMPv4 Need To Fragment packets that indicate an MTU value smaller or equal to 1260. The corresponding value used by [RFC6145] is smaller than 1280.
2. In the IPv6-to-IPv4 direction, an SIIT Gateway MUST NOT generate and maintain any state due to generating IPv4 Identification values. [RFC6145] RECOMMENDS that this is done.

Also see [I-D.gont-6man-deprecate-atomfrag-generation], which seeks to formally update [RFC6145] with the approach described in this section.

5.6. Loop Prevention Mechanism

As noted in Section 9.2, there is a potential for packets looping through the SIIT-DC function if it receives an IPv4 packet for which there is no Static Address Mapping. It is therefore RECOMMENDED that the implementation has a mechanism that automatically prevents this behaviour. One way this could be accomplished would be to discard any IPv4 packets that would be translated into an IPv6 packet that would be routed straight back into the SIIT-DC function.

If such a mechanism isn't provided, the implementation MUST provide a way to manually filter or null-route the destination addresses that would otherwise cause loops.

Relation to [RFC6145]: This security consideration applies only when an SIIT-DC Gateway translates a packet in "pure" SIIT [RFC6145] mode (i.e., both address fields are translated according to [RFC6052]). This consideration is in other words not specific to SIIT-DC, it is inherited from [RFC6145]. In spite of this, [RFC6145] does not describe this consideration or any methods of prevention. The requirements in this section is therefore novel to SIIT-DC, even though they apply equally to [RFC6145].

6. Acknowledgements

The author would like to thank the following individuals for their contributions, suggestions, corrections, and criticisms: Fred Baker, Cameron Byrne, Ross Chandler, Dagfinn Ilmari Mannsaaker, Lars Olafsen, Stig Sandbeck Mathisen, [YOUR NAME GOES HERE].

7. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

8. IANA Considerations

This draft makes no request of the IANA. The RFC Editor may remove this section prior to publication.

9. Security Considerations

9.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 is recommended, 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 the translated IPv4 end users on the Internet will appear to come from within the provider's own IPv6 address space. It is therefore important that the translation prefix is treated the same as the Internet at large, rather than as a trusted network.

9.2. Packets Looping Through the SIIT-DC Function

If the SIIT-DC Gateway receives an IPv4 packet destined to an address for which there is no Static Address Mapping, its destination address will be rewritten according to [RFC6052], making the resulting IPv6 packet have a destination address within the translation prefix, which is likely routed to back to the SIIT-DC function. This will cause the packet to loop until its Time To Live / Hop Limit reaches zero, potentially creating a Denial Of Service vulnerability.

To avoid this, it should be ensured that packets sent to IPv4 destinations addresses for which there are no Static Address Mappings, or whose resulting IPv6 address does not have a more-specific route to the IPv6 network, are immediately discarded.

10. References

10.1. Normative References

10.2. Informative References

Appendix A. Complete SIIT-DC topology example

This figure shows a more complete SIIT-DC topology, in order to better demonstrate the beneficial properties it has. In particular, it tries to highlight the following:

• Stateless operation: Any number of SIIT-DC Gateways may be deployed side-by side, or indeed anywhere in the IPv6 network, as any standard routing mechanism may be used to direct traffic to them (shown here with BGP on the IPv4 side and ECMP on the IPv6 side). This in turn leads to high availability, should one of the SIIT-DC Gateways fail or become unavailable, those standard routing mechanisms will ensure that traffic is automatically redirect one of the remaining SIIT-DC Gateways.
• IPv4 address conservation: Even though the to customers in the example have several hundred servers, most of them are not used for externally available services, and thus do not require an IPv4 address. The network between the servers and the SIIT-DC Gateways require no IPv4 addresses, either. Furthermore, the IPv4 addresses that are used do not have to be assigned to customers in the form of aggregated blocks or prefixes; which makes it easy to achieve 100% effective utilisation of the IPv4 service address pools.
• Application support: The translation-friendly applications HTTP and SMTP will work through SIIT-DC without requiring any special customisation. Furthermore, translation-unfriendly applications such as FTP will also work if an host agent in present, cf. [I-D.anderson-v6ops-siit-dc-2xlat].
• Native IPv6 as the foundation: Every server, application, and network component has access to native and untranslated IPv6 connectivity to each other and to the Internet. Traffic through the SIIT-DC Gateways will diminish over time as IPv6 is deployed throughout the Internet. Eventually they may be shut down entirely, which causes no disruption to the application stacks' ability to deliver their services over native IPv6.

                /--------------------------------\ /---------------\
                |          IPv4 Internet         | | IPv6 Internet |
                \-+----------------------------+-/ \--------+------/
                  |                            |            |
                  | <----------[BGP]---------> |            |
                  |                            |            |
+---------<192.0.2.0/24>----------+ +---<192.0.2.0/24>---+  |
|                                 | |                    |  |
|        SIIT-DC Gateway 1        | | SIIT-DC Gateway 2  |  |
|        =================        | | =================  |  |
|                                 | |                    |  |
|       Translation Prefix:       | |                    |  |
|         2001:db8:46::/96        | |                    |  |
|                                 | |                    |  |
|     Static Address Mappings:    | | Exactly the same   |  |
| 192.0.2.1 <=> 2001:db8:12:34::1 | | configuration as   |  |
| 192.0.2.2 <=> 2001:db8:12:34::2 | | SIIT-DC Gateway 1  |  |
| 192.0.2.3 <=> 2001:db8:fe:dc::1 | |                    |  |
| 192.0.2.4 <=> 2001:db8:12:34::4 | |                    |  |
| [...]                           | |                    |  |
|                                 | |                    |  |
+--------<2001:db8:46::/96>-------+ +-<2001:db8:46::/96>-+  |
                  |                            |            |
                  | <---------[ECMP]---------> |            |
                  |                            |            |
/-----------------+----------------------------+-\          |
|            IPv6 data centre network            +----------+
\-+-----------------------------------+----------/
  |                                   |
  | Customer A's server LAN           | Customer B's server LAN
  | 2001:db8:12:34::/64               | 2001:db8:fe:dc::/64
  |                                   |
  |                                   |
  +-- www      ::1 (IPv6+SIIT-DC)     +-- www ::1 (IPv6+SIIT-DC)
  |                                   |
  |                                   +-- file01 ::f:01 (IPv6)
  +-- mta      ::2 (IPv6+SIIT-DC)     |   [...]                
  |                                   +-- file99 ::f:99 (IPv6) 
  +-- ftp      ::3 (IPv6)             
  |            ::4 (SIIT-DC/Host Agent)
  |                                   
  +-- app01 ::a:01 (IPv6)
  |   [...]
  +-  app99 ::a:99 (IPv6)
  |
  +-- db01  ::d:01 (IPv6)
  |   [..]
  +-- db99  ::d:99 (IPv6)