IPv6 Operations                                              T. Anderson
Internet-Draft                                            Redpill Linpro
Intended status: Standards Track                       December 18, 2014
Expires: Informational                             June 21, 28, 2015
Expires: December 30, 2015

SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments


   This document describes SIIT-DC, an extension to the use of the Stateless IP/
   ICMP IP/ICMP Translation
   (SIIT) algorithm, that makes it ideally suited for
   use algorithm in an IPv6 data centre environments.  SIIT-DC simultaneously
   facilitates IPv6 Internet Data Centre (IDC).  In this
   deployment and IPv4 address conservation.  The
   overall SIIT-DC architecture model, traffic from legacy IPv4-only clients on the
   Internet is described, translated to IPv6 when reaches the IDC operator's
   network infrastructure.  From that point on, it is treated just as if
   it was traffic from any other IPv6-capable end user.  This
   facilitates a single-stack IPv6-only network infrastructure, as well
   as guidelines for
   operators.  Finally, the normative implementation requirements efficient utilisation of public IPv4 addresses.

   The primary audience is IDC operators who are
   described, as a list deploying IPv6, running
   out of additions and changes to SIIT. available IPv4 addresses, and/or feel that dual stack causes
   undesirable operational complexity.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 21, December 30, 2015.

Copyright Notice

   Copyright (c) 2014 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Motivation and Goals  . . . . . . . . . . . . . . . . . .   3
       1.1.1.  Single Stack IPv6 Operation . . . . . . . . . . . . .   4
       1.1.2. . .   3
     1.2.  Stateless Operation . . . . . . . . . . . . . . . . . . .   4
     1.3.  IPv4 Address Conservation . . . . . . . . . . . . . .   5
       1.1.4.  No Loss of End User's IPv4 Source Address . . . . .   4
     1.4.  Clients' IPv4 Source Addresses Visible to Applications  .   5
     1.5.  Compatible with Standard IPv6 Implementations . . . .   5
       1.1.6.  No Architectural Dependency on IPv4 and IPv6 Stacks . . . . . . . . .   6   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6   5
   3.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   7
     3.1.  DNS Configuration . . . . . . . . . . . . . . . . . . . .   9
     3.2.  Packet Flow . . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Deployment Considerations and Guidelines  . . . . . . . . . . . . . . . . . . . .  11  10
     4.1.  Application  Application/Device Support for NAT . . . . IPv6 . . . . . . . . . . .  12  10
     4.2.  Application Support for IPv6 NAT . . . . . . . . . . . . . .  12 .  10
     4.3.  Application Communication Pattern . . . . . . . . . . . .  12  10
     4.4.  Choice of Translation Prefix  . . . . . . . . . . . . . .  13  11
     4.5.  Routing Considerations  . . . . . . . . . . . . . . . . .  13  12
     4.6.  Location of the SIIT-DC Gateways  . Border Relays . . . . . . . . . . .  14  12
     4.7.  Migration from Dual Stack . . . . . . . . . . . . . . . .  15  13
     4.8.  Packet Size and Fragmentation Considerations  Translation of ICMPv6 Errors to IPv4  . . . . . .  15
       4.8.1.  IPv4/IPv6 Header Size Difference . . . .  13
     4.9.  MTU and Fragmentation . . . . . .  16
       4.8.2.  IPv6 Atomic Fragments . . . . . . . . . . . . . . . .  16
       4.8.3.  Minimum Path MTU  13
       4.9.1.  IPv4/IPv6 Header Size Difference Between IPv4 and IPv6 . .  17
   5.  Implementation Requirements . . . . . . . . . . . .  . . . . .  18
     5.1.  Compliance with RFC6145 and RFC6052 . . . . . . . .  14
       4.9.2.  IPv6 Atomic Fragments . . .  18
     5.2.  Static Address Mapping Function . . . . . . . . . . . . .  19
     5.3.  Support for Increasing the IPv6  14
       4.9.3.  Minimum Path MTU Difference Between IPv4 and IPv6 . . . . . . . .  19
     5.4.  Loop Prevention Mechanism . . . . . . . .  15
     4.10. IPv4-translatable IPv6 Service Addresses  . . . . . . . .  20
   6.  16
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20
   7.  Requirements Language . . . . . . . . . . . . . . . . . . . .  20
   8.  17
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   9.  17
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
     9.1.  17
     7.1.  Mistaking the Translation Prefix for a Trusted Network  .  21
     9.2.  Packets Looping Through the SIIT-DC Function  . . . . . .  21
   10.  17
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     10.1.  17
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
     10.2.  17
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  21  18
   Appendix A.  Complete SIIT-DC IDC topology example  . . . . . . . . .  23
   Appendix B.  Comparison to Other Deployment Approaches  . . . . .  26
     B.1.  IPv4-only . . . . . . . . . . . . . . . . . . . . . . . .  26
     B.2.  IPv4-only + NAPT44  . . . . . . . . . . . . . . . . . . .  26
     B.3.  IPv4-only + NAT64 . . . . . . . . . . . . . . . . . . . .  28
     B.4.  Dual Stack  . . . . . . . . . . . . . . . . . . . . . . .  29
     B.5.  Partial Dual Stack (IPv6-only back-end) . . . . . . . . .  30  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  31  23

1.  Introduction

   SIIT-DC is an extension of SIIT [RFC6145] that provides a network-
   centric stateless translation service that allows a data centre
   operator or Internet Content Provider (ICP) to run a data centre
   network, servers, and applications using exclusively IPv6, while at
   the same time ensuring that end users that have only IPv4
   connectivity will be able to continue to access the services and

1.1.  Motivation and Goals

   Historically, dual stack [RFC4213] [RFC6883] has been the recommended
   way to transition from an a legacy IPv4-only environment to one capable
   of serving IPv6 users.  However, for data centre operators and Internet
   content providers, IDC operators, dual stack
   operation has a number of disadvantages compared to single stack
   operation.  In particular, running two protocols rather than one
   results in increased complexity and operational overhead, with a very low expected little
   return on investment
   in the short to medium term while few end-users only have
   connectivity to for as long as large parts of the IPv6 Internet. public
   Internet remains predominantly IPv4-only.  Furthermore, the dual
   stack approach does not in any way help with the depletion of the
   IPv4 address space. space, which at the time of writing is a pressing
   concern in most parts of the world.

   Therefore, some IDC operators may instead prefer an approach in which
   they only need to operate one protocol in the data centre as they
   prepare for the future.  The  SIIT-DC is one such approach.  Its design
   goals are: include:

   o  Promote the deployment of native IPv6 services (cf. [RFC6540]).

   o  Provide IPv4 service availability for legacy users with no loss of
      performance or functionality.

   o  To ensure that that the legacy users' IPv4 addresses remain
      visible to the servers nodes and applications.

   o  To conserve and maximise the utilisation of the operator's public
      IPv4 addresses.

   o  To avoid introducing more complexity than absolutely necessary,
      especially on the servers nodes and applications.

   o  To be easy to scale and deploy in a fault-tolerant manner.

   The following subsections elaborates on how SIIT-DC meets these


1.1.  Single Stack IPv6 Operation

   SIIT-DC allows an operator IDC operators to build their infrastructure and
   applications on an IPv6-only foundation.  IPv4 end-user connectivity
   becomes a service provided by the network, which systems
   administration and application development staff do not need to
   concern themselves with.

   Obviously, this will promote  This promotes universal IPv6 deployment for all of
   provider's IDC operator's services and applications.

   It is worth noting that

   SIIT-DC requires no special support or change from the underlying
   IPv6 infrastructure, it will work is compatible with any kind
   of all standard IPv6 network.
   networks.  Traffic between IPv6-enabled end users and IPv6-enabled
   services will always be native, and transported native end-to-end; SIIT-DC will does
   not be
   involved in it intercept or handle native IPv6 traffic at all.


   When the day comes to discontinue all support for IPv4, no change
   needs to be made to the overall architecture - it's only a matter of
   shutting off the BRs.  Operators who deploy native IPv6 along with
   SIIT-DC will thus avoid requiring any future migration or deployment
   projects relating to IPv6 deployment and/or IPv4 sun-setting.

1.2.  Stateless Operation

   Unlike other solutions that provide either dual stack availability to
   single-stack services (e.g., Stateful NAT64 [RFC6146] and Layer-4/7
   proxies), or that provide conservation of IPv4 addresses (e.g.,
   NAPT44 [RFC3022]), a SIIT-DC Gateway does not keep any state between each
   packet in a single connection or flow.  In this sense it operates
   exactly like a normal regular IP router, and has similar scaling properties
   - the limiting factors are packets per second and bandwidth.  The
   number of concurrent flows and flow initiation rates are irrelevant
   for performance.

   This not only allows individual SIIT-DC Gateways BRs to easily attain "line rate"
   performance, it also allows for per-packet load balancing between
   multiple SIIT-DC Gateways BRs using Equal-Cost Multipath Routing [RFC2991].
   Asymmetric routing is also acceptable, which makes it easy to avoid
   sub-optimal traffic patterns; the prefixes involved may be anycasted
   from all the SIIT-DC Gateways BRs in the provider's network, thus ensuring that the
   most optimal path through the network is used, even where the optimal
   path in one direction differs from the optimal path in the opposite

   Finally, stateless operation means that high availability is easily
   achieved.  If an SIIT-DC Gateway a BR should fail, its traffic can be re-
   routed re-routed onto
   another SIIT-DC Gateway BR using a standard IP routing protocol.  This does not
   impact existing flows any more than what any other IP re-routing
   event would.


1.3.  IPv4 Address Conservation

   In most parts of the world, it is difficult or even impossible to
   obtain generously sized IPv4 allocations delegation from the Regional Internet
   Registries. Numbers
   Registry System [RFC7020].  The resulting scarcity in turn impacts
   individual end users and operators, which might be forced to purchase
   IPv4 addresses from other operators in order to cover their needs.
   This process can be risky to business continuity, in the case no
   suitable block for sale can be located, and/or turn out to be
   prohibitively expensive.
   Even so, a data centre  In spite of this, an IDC operator will find
   that providing IPv4 service
   is remains essential, as a large share of
   the Internet end users still does do not have IPv6 connectivity.

   A key goal of SIIT-DC is to help reduce a data centre operator's IPv4
   address requirement to the absolute minimum, by allowing the operator
   to remove them entirely from components nodes and applications that do not need
   to communicate with endpoints in the IPv4 Internet.  One example
   would be servers that are operating in a supporting/back-end role and
   only communicates with to other servers (database servers, file
   servers, and so on).  Another example would be the network
   infrastructure itself (router-to-router links, loopback addresses,
   and so on).  Furthermore, as LAN prefix sizes must always be rounded
   up to the nearest power of two (or larger, if one reserves space for
   future growth), even more IPv4 addresses will often end up being
   wasted without even being used.

   With SIIT-DC, the operator can remove these valuable IPv4 addresses
   from his back-end servers and network infrastructure, and reassign
   them to the SIIT-DC service as IPv4 Service Addresses.  There is exists
   no requirement that IPv4 Service Addresses are assigned in an
   aggregated manner, so there is nothing lost due to infrastructure
   overhead; every single IPv4 address assigned to SIIT-DC can be used
   an IPv4 Service Address.

1.1.4.  No Loss of End User's

1.4.  Clients' IPv4 Source Address Addresses Visible to Applications

   SIIT-DC will uses the [RFC6052] algorithm to map the entire end-user's
   IPv4 source address into an predefined IPv6 translation prefix. Translation Prefix.  This
   ensures that there is no loss of information; the end-user's IPv4
   source address remains available to the server/application, application, allowing it to
   perform tasks like Geo-Location, logging, abuse handling, and so


1.5.  Compatible with Standard IPv4 and IPv6 Implementations Stacks

   Except for the introduction of the SIIT-DC Gateways BRs themselves, no change to the
   network, servers, nodes, applications, or anything else is required in order
   to support SIIT-DC.  SIIT-DC is practically invisible from the point
   of view of the the IPv4 clients, the IPv6
   servers, nodes, the IPv6 data centre
   network, and the IPv4 Internet.  SIIT-
   DC  SIIT-DC interoperates with all
   standards-compliant IPv4 or IPv6 stacks.

1.1.6.  No Architectural Dependency on IPv4

   SIIT-DC will allow an ICP or data centre operator to build
   infrastructure and applications entirely on IPv6.  This means that
   when the day comes to discontinue support for IPv4, no change needs
   to be made to the overall architecture - it's only a matter of
   shutting off the SIIT-DC Gateways.  Therefore, by deploying native
   IPv6 along with SIIT-DC, operators will avoid future migration or
   deployment projects relating to IPv6 roll-out and/or IPv4 sun-

2.  Terminology

   This document makes use of the following terms:

   SIIT-DC Border Relay (BR)
      A device or a logical function that performs stateless protocol
      translation between IPv4 and IPv6 in accordance with [RFC6145] and

   SIIT-DC Edge Relay (ER)
      A device or logical function that provides "native" IPv4
      connectivity to IPv4-only devices or application software.  It is
      very similar in function to a BR, but is typically located close
      to the IPv4-only component(s) it is supporting rather than on the
      IDC's outer network border.  The ERs is an optional component of
      SIIT-DC.  It is discussed in more detail in

   IPv4 Service Address
      A public IPv4 address with which IPv4-only clients will communicate. communicates.
      This communication will be translated to IPv6 by a BR.  The
      service's "IN A" DNS record will typically point to the SIIT-DC Gateway. IPv4
      Service Address.

   IPv4 Service Address Pool
      One or more IPv4 prefixes routed to the
      SIIT-DC Gateway's BR's IPv4 interface.  IPv4
      Service Addresses are allocated from this pool.  Note that  That this does
      not necessarily have to be a "pool" per se, as it could also be
      one or more host routes (whose prefix length is equal to /32).
      The primary purpose of using a pool rather than host routes is to
      facilitate IPv4 route aggregation and ease provisioning of new
      IPv4 Service Addresses.

   IPv6 Service Address
      A public IPv6 address assigned to a node (such as a server or
      load-balancer) or an individual application in the IPv6 network.  IPv6-only and dual stacked
      IPv6-capable clients communicates with this address communicate directly without invoking
      SIIT-DC. with the IPv6 Service
      Address using native IPv6.  The service's "IN AAAA" DNS record
      will typically point to the IPv6 Service Address.  IPv4-only
      clients also communicates indirectly communicate with this address
      through the SIIT-DC Gateway and via IPv6 Service Address
      through SIIT-DC.

   Explicit Address Mapping (EAM)
      A bi-directional coupling between an IPv4 Service Address.

   SIIT-DC Host Agent  A logical function very similar to Address and an SIIT-DC
      Gateway that resides on
      IPv6 Service Address configured in a server and provides virtual BR or ER.  When translating
      between IPv4
      connectivity to applications, by reversing and IPv6, the translations done
      by the SIIT-DC Gateway.  It is an optional component of the SIIT-
      DC architecture, that may be used to increase application support.
      See [I-D.anderson-v6ops-siit-dc-2xlat].

   SIIT-DC Gateway  A device or a logical function that translates
      between IPv4 and IPv6 in accordance with Section 5.

   Static Address Mapping  A bi-directional mapping between an IPv4
      Service Address and an IPv6 Service Address configured in the
      SIIT-DC Gateway.  When translating between IPv4 and IPv6, the
      SIIT-DC Gateway changes BR/ER changes the address fields in the
      translated packet's IP header according to any matching Static Address
      Mapping. EAM.  See

   Translation Prefix
      An IPv6 prefix into which the entire IPv4 address space is mapped.
      This prefix is routed to the SIIT-DC Gateway's BR's IPv6 interface.  It is either an a
      Network-Specific Prefix or a the Well-Known Prefix as specified in 64:ff9b::/96, cf.
      [RFC6052].  When translating between IPv4 and IPv6, the SIIT-DC Gateway prepends a BR/ER
      inserts or strips removes the Translation Prefix from the address fields
      in the translated packet's IP header, unless a Static Address Mapping exists an EAM for the IP
      address being translated exists.

   IPv4-translatable IPv6 addresses
      As defined in Section 1.3 of [RFC6052].

      Short for "Internet Data Centre"; a data centre whose main purpose
      is to deliver services to the public Internet, the use case SIIT-
      DC is primarily targeted at.  IDCs are typically operated by
      Internet Content Providers or Managed Services Providers.

      The Stateless IP/ICMP Translation algorithm, as specified in

      Short for "translation".

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in question. [RFC2119].

3.  Architectural Overview

   This section describes the basic SIIT-DC architecture.

                           SIIT-DC Architecture

             +-------------------+         +----------------+

              IPv6-capable user |         |      IPv4-only user |
             | ================= |         | ============== |
             |                   |         |                |
             +-<2001:db8::ab:cd>-+         +-<>-+
              <2001:db8::ab:cd>      <>
                |                          |
             (the IPv6 internet)   (the IPv4 Internet)
                |                          |
                |        +------------------<>-+
                 |  +-[BR]---------<>--------------+
                |  |                                          |
                |         SIIT-DC Gateway         |  |        |         =============== EAM #1:,2001:db8:12:34::1 |
                |  | EAM #2..#n:  [...]                       |
                |  |       Translation XLAT Prefix:       |
                 |        | 2001:db8:46::/96            |
                |  |                                          |
                |        |     Static Address Mapping:     |
                 |        | <=> 2001:db8:12:34::1 |
                 |        |                                 |
                 |        +--------------<2001:db8:46::/96>-+  +------------<2001:db8:46::/96>------------+
                |                        |
               (the IPv6-only data centre network)
                           |                               |
                 | ------------------------------/
            +--<2001:db8:12:34::1>--[v6-only server]-+
            |     |                                  |
            |          IPv6-only server                   |
           |     |          ================                   |
           |     |                                             |
           | +-[2001:db8:12:34::1]---------------------------+ +-[2001:db8:12:34::1]--[v6-only app]-+ |
            | |   AF_INET6 socket                  | |
            | +------------------------------------+ |                                               | |
           | |             IPv6-only application             | |
           | |                                               | |
           | +-----------------------------------------------+ |

                                 Figure 1

   In this example, Figure 1, is allocated as an the IPv4 Service Address Pool.
   Individual IPv4 Service Addresses are assigned from this pool.
   The provider must route this prefix prefix, and
   traffic destined for it is routed to the SIIT-DC Gateway's IPv4 BR's IPv4-facing network
   interface.  Note that there  There are no restrictions on how many IPv4 Service
   Address Pools are used or their prefix length, as long as they are
   all routed to the SIIT-DC Gateway's IPv4 BR's IPv4-facing network interface.

   The Static Address Mapping list is used when

   When translating an packets between IPv4
   Service Address (here to its corresponding IPv6 Service
   Address (here 2001:db8:12:34::1) and vice versa.  When IPv6, the SIIT-DC
   Gateway translates an IPv4 packet BR uses the EAM
   to IPv6, replace any occurrence of the IPv4 Service Address
   found in the original IPv4 header will be replaced (
   with the its corresponding IPv6 Service Address (2001:db8:12:34::1).
   Addresses that do not match any EAM configured in the resulting IPv6 header, and
   vice versa when translating an IPv6 packet to IPv4.

   2001:db8:46::/96 is BR are
   translated by inserting or removing the Translation Prefix into which the entire IPv4
   address space is mapped.  It is used for translation of the end
   user's IPv4 address to IPv6 and vice versa according to the algorithm
   defined in
   (2001:db8:46::/96), cf. Section 2.2 of RFC6052 [RFC6052].  This algorithmic
   mapping has a lower precedence than the configured Static Address

   The SIIT-DC Gateway itself BR can be either deployed as a separate device or as a logical function
   in another multi-purpose device, for example such as an IP router.  Any number of SIIT-DC Gateways
   BRs may exist simultaneously in
   an operators the IDC's network infrastructure, as
   long as they all have configured with the same
   translation prefix Translation Prefix and list of Static Mappings configured.

3.1.  DNS Configuration an
   identical EAM Table.

   The IPv6 Service Address of should be registered in DNS using an "IN
   AAAA" record, while its corresponding IPv4 Service Address should be
   registered using an "IN A" record.  This results in ensures that IPv6-capable
   clients access the following DNS

              DNS Configuration for a SIIT-DC enabled service

               www.example.com.  IN AAAA  2001:db8:12:34::1
               www.example.com.  IN A

                                 Figure 2

3.2. application/service directly using its native IPv6
   end-to-end, while IP4-only clients will access it through SIIT-DC.

3.1.  Packet Flow

   In this example, the "IPv4-only user" from Figure 1 initiates a request
   connection to the application running on the IPv6-only server.  He starts by looking  After
   first having looked up the "IN A" record of "www.example.org" in DNS, and attempts to
   connect to this address on the service user starts by
   transmitting the following
   IPv4 an TCP SYN packet destined for to the IPv4 Service Address:

                      Stage 1: Client -> Server, IPv4

            | IP Version:           4                        |
            | Source Address:             |
            | Destination Address:                |
            | Protocol:             TCP                      |
            | TCP SYN [...]                                  |

                                 Figure 3 Address.  This
   IPv4 packet is then routed over the Internet to the (nearest) SIIT-DC
   Gateway, which translates it into the following IPv6 packet BR, and
   forward it into the is there translated to IPv6 network:

                  Stage 2: Client -> Server request, as


            +-------------------------------------------------+ to IPv6 translation

        +--[IPv4]----------+     +--[IPv6]-----------------------+
        | IP Version:           6 SRC |     | Source Address: SRC 2001:db8:46:: |
        | Destination Address: DST    | --> | DST 2001:db8:12:34::1         |
        | Next Header: TCP SYN [..]     |
            |-------------------------------------------------|     | TCP SYN [...] [..]                  |
        +------------------+     +-------------------------------+

                                 Figure 4 2

   The destination address field was translated resulting IPv6 packet is routed to the IPv6 Service
   Address according to the configured Static Address Mapping, while the
   source address was field translated according to the [RFC6052]
   mapping using the Translation Prefix (because it did not match any
   Static Address Mapping).  The rest of the IP header was translated
   according to [RFC6145].  The Layer 4 payload is copied verbatim, with
   the exception of the TCP checksum being recalculated.

   Note that the IPv6 address 2001:db8:46:: may also be
   expressed as 2001:db8:46::cb00:7132, cf. Section 2.2 of RFC4291

   Next, the application receives receives this IPv6 packet IPv6-only server, which
   processes and responds to it like as if it would with any other IPv6 packet:

                 Stage 3: Server -> Client response, had been a native IPv6

            | IP Version:           6                         |
            | Source Address:       2001:db8:12:34::1         |
            | Destination Address:  2001:db8:46:: |
            | Next Header:          TCP                       |
            | TCP SYN+ACK [...]                               |

                                 Figure 5 packet
   all along.  The server's IPv6 response packet is then routed back to
   the (nearest) SIIT-DC Gateway's IPv6
   interface, which will translate BR, where it is translated back to IPv4 as follows:

                 Stage 4: Server -> Client response,

                         IPv6 to IPv4

            +------------------------------------------------+ translation

        +--[IPv6]-----------------------+      +--[IPv4]----------+
        | IP Version:           4 SRC 2001:db8:12:34::1         |      | Source Address: SRC    |
        | DST 2001:db8:46:: | -->  | Destination Address: DST |
        | Protocol: TCP SYN/ACK [..]              |
            |------------------------------------------------|      | TCP SYN+ACK [...] 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 3

   It is transmitted back important to note that neither 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, client nor does the server's IPv6 stack have
   server/application need any idea that
   is is communicating with an IPv4 client.  To them, it's just plain
   IPv4 or IPv6, respectively. special support to participate in SIIT-
   DC.  However, the applications running on the
   server application may optionally be updated taught to recognise and strip the
   Translation Prefix, so that extract the end user's
   embedded IPv4 source address may be used
   for logging, 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 forth. on.

4.  Deployment Considerations and Guidelines

4.1.  Application/Device Support for IPv6

   SIIT-DC as described in this section, we list recommendations document requires that the application
   (and/or the node the application is located on) supports IPv6
   networking, and guidelines for operators
   who would like to deploy a that it has no dependency on local IPv4 network
   connectivity.  However, SIIT-DC service supports IPv4-dependent applications
   and nodes through the introduction of an ER.  The ER provides the
   application or node with seemingly native IPv4 connectivity, by
   translating the packets (that were previously translated from IPv4 to
   IPv6) by the BR back to IPv4 before passing them to the
   IPv4-dependent application or node.  This approach is described in their data centre

   more detail in [I-D.ietf-v6ops-siit-dc-2xlat].

4.2.  Application Support for NAT

   Not all

   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.  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 particularly problematic [RFC2663] [RFC2993] [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  Such
   protocols can be extended made to work with a Host Agent that
   reverses SIIT-DC through the translation introduction
   of an ER, which provides end-to-end IPv4 address transparency by
   reversing the translations performed by the SIIT-DC Gateway BR before passing the
   packets to the application software. NAT-incompatible application.  This allows the
   problematic application protocols approach is
   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

4.2. more detail in [I-D.ietf-v6ops-siit-dc-2xlat].

4.3.  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

4.3.  Application Communication Pattern Communication Pattern

   SIIT-DC is ideally best suited for traditional client/server applications
   where IPv4-only nodes clients on the Internet initiate traffic towards the an
   IPv6-only services, service, which in turn are only is passively listening for inbound
   traffic and responding as necessary.  One well-known example of such a protocol
   is HTTP [RFC7230].  This is due to the fact that in  In this case, an IPv4 user client
   looks exactly like an ordinary native IPv6 user client from the host and
   application's IPv6 service's
   point of view, and requires no 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 an SIIT-DC Gateway. SIIT-DC.  However, in this case, care must be
   taken so that all outgoing communication is sourced from
   the an IPv6
   Service Address that has a Static Mapping is found in an EAM configured on in the
   SIIT-DC Gateway. BR.  If
   another unmapped address is used, the SIIT-DC
   Gateway BR will discard most likely be unable to
   translate it to IPv4, causing the packet. 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 make use of place an SIIT-
   DC Host Agent ER in front
   of the application in question, as described in [I-D.anderson-v6ops-siit-dc-2xlat].
   [I-D.ietf-v6ops-siit-dc-2xlat].  This provides the application with
   seemingly native IPv4 connectivity, which it may use freely for both inbound and outbound bi-
   directional communication without requiring with the IPv4 Internet.  An application or
   node located behind an ER does not need to select worry about selecting a
   specific source address for its outbound communications. address, as it will only have valid options

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
   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 must be used anyway for all but one of those


   Another consideration is that the WKP cannot be used in inter-domain
   routing.  By using an NSP, a provider NSP instead, SIIT-DC will have support a deployment
   where 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 BR and the choice of translation prefix IPv6 Service Address are located in more detail. different
   Autonomous Systems.

   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::" (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

   For the reasons discussed above, this document recommends that an NSP
   with a /96 prefix length of /96 is therefore recommended. 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 SIIT-DC Gateway(s) BRs as any other IPv4 or
   IPv6 route in the provider's network.  If more than one SIIT-DC Gateway BR is being
   deployed, it is recommended that a dynamic routing protocol (such as BGP, IS-IS, or OSPF) is
   being (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 SIIT-DC Gateway, BR,
   reducing or eliminating sub-optimal traffic patterns, as well as provide
   providing high availability - if availability: Should one SIIT-
   DC Gateway fails, BR fail, the dynamic routing protocol IGP will
   automatically redirect the traffic to the next-best translator. closest alternate BR.

4.6.  Location of the SIIT-DC Gateways 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 SIIT-DC Gateways BRs and the network infrastructure required to
   connect them the BRs to the IPv4 Internet.  Therefore, the SIIT-
   DC Gateways should BRs must be
   located somewhere between the IPv4 Internet and the application
   delivery stack.  This should be understood to include 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 SIIT-DC Gateways BRs as close as possible to the direct
   path between the servers location of the IPv6 Service Address and the end
   users.  If the closest translator is BR was located a long way from the optimal direct
   path, all packets in both directions must make a detour. detour in order to
   traverse the BR.  This would increase the RTT between the server 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 SIIT-DC Gateways BRs as a logical
   function within the routers would have handled the traffic anyway,
   had the topology been dual stacked.  This way, the
   translation service would a SIIT-DC deployment
   does not need to be assigned require separate networks ports (which might become
   saturated and impact the service quality), nor would will it require extra
   rack space and energy.  Some particularly good choices of the
   location could be within a data centre's an IDC's access routers, or within the provider's
   Autonomous System's border routers.  When every single
   application in the data centre or the provider's network eventually
   runs on single-stack IPv6, there would no need to run IPv4 on the
   inside of the SIIT-DC Gateway.  This reduces complexity, and allows
   the operator to reclaim IPv4 addresses from the network
   infrastructure that may instead be used as IPv4 Service Address

   Finally, another possibility is that the data centre IDC operator outsources the
   SIIT-DC service to another entity, for example his upstream ISP.
   Doing so allows the data centre IDC operator to build a true IPv6-only
   infrastructure.  However, in this case, care must be
   taken to ensure that the path between the data centre and the SIIT-DC
   operator has a stable and known MTU, and that the SIIT-DC Gateways
   are not too far away from the data centre (otherwise, translated
   traffic could incur a latency penalty).

4.7.  Migration from Dual Stack

   While this document mainly discusses the use of IPv6-only servers nodes and
   applications, there it is no technical requirement important to note that the servers are
   IPv4 free. SIIT-DC works equally well for is fully
   compatible with dual stacked servers,
   which makes migration easy - after setting up the translation
   function, the DNS "IN A" record for the stack infrastructures, including dual stack
   nodes and applications.

   Thus, migrating a dual-stacked service is updated to point to an IPv6-only one where
   SIIT-DC provides the IPv4 address that will be translated to IPv6, Internet connectivity is easy.  The
   operator would start out by designating the previously
   used IPv4 service service's current native
   IPv6 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 IPv6 Service Address, and assign it was before.

   It is also possible to use DNS Round Robin to gradually migrate a
   dual-stacked service's
   corresponding IPv4 traffic from native to SIIT-DC.  This is
   done by configuring multiple DNS "IN A" records for the service's
   hostname, and pointing one portion of them to Service Address.  At this point, the service's native service will
   respond on both its old (native) IPv4 addresses address, and another portion to the SIIT-DC IPv4
   Service Addresses handled
   by SIIT-DC. Address.  The distribution of "IN A" records determines how much
   of the client traffic will pass through the SIIT-DC Gateway and how
   much will remain native.  This operator may then gradually increase now move traffic from the share of SIIT-DC former
   to the latter by changing the service's "IN A" DNS records until no native addresses

   When record.  Once all client
   IPv4 traffic is handled by has been successfully moved to SIIT-DC, the operator old IPv4
   address may
   proceed be reclaimed.

4.8.  Translation of ICMPv6 Errors to remove the (now unused) IPv4 addresses assigned

   In response to an IPv4 packet subsequently translated to IPv6 by the
   BR, an IPv6 router in question.  They could then potentially be recycled as
   another the IDC network may need to transmit an ICMPv6
   error back to the origin IPv4 Service Address Pool assigned 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 SIIT-DC.

4.8.  Packet Size 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

4.9.  MTU and Fragmentation Considerations

   There are some key differences between IPv4 and IPv6 relating to
   packet sizes and fragmentation 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 following
   subsections will discuss these in detail, and provide operational

   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, as the IPv6 server node will advertise a TCP MSS of 1440 bytes. bytes during
   the initial TCP handshake.  This causes the client to 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 SIIT-DC Gateway.  The
   only way to avoid this is to increase BR.  This may be
   avoided by increasing the Path MTU between the SIIT-
   DC Gateway BR and the servers IPv6 nodes
   to 1520 bytes.  Note that bytes or greater.  If this is done, the servers' MTU on the IPv6 nodes
   themselves SHOULD NOT be increased accordingly, as that doing so would
   cause them to undergo Path MTU Discovery for most native IPv6 destinations.
   However, all destinations on the servers would need to
   IPv6 Internet.  The nodes MUST however be able to accept and process
   incoming packets larger than their own MTU.  If the server's nodes' IPv6
   implementation allows the initial Path MTU to be set differently for
   specific destinations, it could 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
   [RFC6145], an SIIT-DC Gateway 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 a data
   centre an IDC
   environment, and it is therefore recommended that this behaviour is
   disabled in the SIIT-DC Gateways. BRs.  To this end, Section 4 of RFC6145 [RFC6145]
   notes that the "translator MAY provide a configuration function that
   allows the translator not to include the Fragment Header for the non-fragmented non-
   fragmented IPv6 packets".

   Note that [I-D.ietf-6man-deprecate-atomfrag-generation] seeks to
   update [RFC6145], making the functionality described above as the
   standard and only mode of operation.

   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


4.9.3.  Minimum Path MTU Difference Between IPv4 and IPv6

   Section 5 of RFC2460 [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 fails might prove false if the destination is an
   IPv4 node reached through a protocol translator such as an SIIT-DC Gateway, a BR, as the
   minimum IPv4 link MTU is 68 bytes.  See Section 3.2 of RFC791

   Section 5.1 of RFC6145 [RFC6145] specifies that an SIIT-DC Gateway 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.8.1), 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 SIIT-DC Gateway 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 [RFC2460] gives it two choices on how to proceed:

   o  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 SIIT-DC
      Gateway. BR.

   o  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
      SIIT-DC Gateway 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 [RFC6145].  This
   functionality changes the SIIT-DC Gateway's BR's behaviour as follows:

   o  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

   o  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 [RFC2460].  Note that
   [I-D.ietf-6man-deprecate-atomfrag-generation] seeks to update
   [RFC6145], making the approach described above as the standard and
   only mode of operation.

5.  Implementation Requirements

   This normative section specifies the

4.10.  IPv4-translatable IPv6 Service Addresses

   SIIT-DC protocol that is
   implemented by an SIIT-DC Gateway.  Because SIIT-DC builds on and
   closely resembles SIIT [RFC6145], this section should be read as a
   set of additions and changes designed so that the IPv6 Service Addresses are applied to an implementation
   already compliant not
   required to SIIT [RFC6145].  Each be IPv4-translatable IPv6 addresses.  Section 2 of the following
   subsections discuss how the requirement relates I-D
   .ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam] discusses why it is
   desirable to with any
   corresponding requirements in SIIT [RFC6145].

5.1.  Compliance with RFC6145 and RFC6052
   Unless otherwise stated in avoid requiring the following sections, an use of IPv4-translatable IPv6

   It is however quite possible to deploy SIIT-DC
   implementation MUST comply fully in combination with [RFC6145].  It must also
   implement the algorithmic address mapping defined
   IPv4-translatable IPv6 Service Addresses.  The primary benefits in [RFC6052].

5.2.  Static Address Mapping Function
   doing so are:

   o  The implementation MUST allow the operator is not required to configure an arbitrary
   number of Static Address Mappings which override provision EAMs for
      IPv4-translatable IPv6 Service Addresses onto the default
   [RFC6052] algorithm.  It SHOULD BR/ERs.

   o  [RFC6145] translation can be possible to specify performed in a single bi-
   directional mapping checksum-neutral
      manner, cf. Section 4.1 of RFC6052 [RFC6052].

   The trade-off is that will the IPv4-translatable IPv6 Service Addresses
   must be used in both configured on the IPv4=>IPv6 IPv6 nodes, and
   IPv6=>IPv4 directions, but it MAY additionally (or alternatively)
   support unidirectional mappings.

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

   o <=> 2001:db8:12:34::1

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

   o => 2001:db8:12:34::1

   o  2001:db8:12:34::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 as the either the source
   or destination field of the IPv4 header, it MUST rewrite this field
   set up to 2001:db8:12:34::1 when translating use them - likely in addition to IPv6.  For all IPv4 or their primary (non-
   IPv4-translatable) IPv6
   source or destination field values for which there are no matching
   Static Address Mapping, [RFC6052] compliant mapping MUST be used

   Relation to [RFC6145]: addresses.  The Static Address Mapping is a novel feature
   feature that is not discussed in [RFC6145].  It conflicts with the
   [RFC6145] requirement that all addresses IPv4-translatable IPv6
   Service Addresses must also be translated according
   to routed from the [RFC6052] algorithm.

5.3.  Support for Increasing BR through the IDC's
   IPv6 Path MTU

   The SIIT-DC Gateway MUST provide a configuration function for the network administrator infrastructure to adjust the threshold of nodes on which they are assigned.
   This essentially requires the minimum entire IPv6 MTU infrastructure to be made
   aware of and handle translated IPv4 traffic as a value that reflects the real value special case, which
   significantly increases complexity.  Avoiding such drawbacks is a
   design goal of SIIT-DC, cf.  Section 1.1, therefore the minimum IPv6 MTU in
   the network (greater than 1280 bytes).  This will help reduce the
   chance use of including the Fragment Header in the resulting
   IPv4-translatable IPv6

   Relation Service Addresses is discouraged.

5.  Acknowledgements

   The author would like to [RFC6145]: This strengthens thank the corresponding "MAY"
   requirement located in Section 4 of RFC6145 [RFC6145] to a "MUST".

5.4.  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., when 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 following individuals for their
   contributions, suggestions, corrections, and criticisms: Fred Baker,
   Cameron Byrne, Brian E Carpenter, Ross Chandler, Dagfinn Ilmari
   Mannsaaker, Lars Olafsen, Stig Sandbeck Mathisen, Knut A. Syed,
   Andrew Yourtchenko.

7.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].


6.  IANA Considerations

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


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 is recommended, 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 the traffic
   from translated IPv4 end users on the Internet will might appear to be located within
   originating from the provider's own IPv6 address space. network.  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


   In order to alleviate this problem, the SIIT-DC Gateway receives an IPv4 packet destined operator may opt to an address
   for which there use a
   Translation Prefix that is no Static Address Mapping, its destination address
   will be rewritten according to [RFC6052], making the resulting IPv6
   packet have distinct from and not a destination address within subset of the translation prefix,
   which is likely routed to back to IPv6
   prefixes used elsewhere in 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. network infrastructure.

8.  References


8.1.  Normative References

              Anderson, T. and A. Leiva, "Explicit Address Mappings for
              Stateless IP/ICMP Translation", draft-ietf-v6ops-siit-
              eam-00 (work in progress), May 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, April 2011.


   [RFC6791]  Li, X., Bao, C., Wing, D., Vaithianathan, R., and G.
              Huston, "Stateless Source Address Mapping for ICMPv6
              Packets", RFC 6791, November 2012.

8.2.  Informative References

              tore, t., "SIIT-DC: Dual Translation Mode", draft-
              anderson-v6ops-siit-dc-2xlat-00 (work in progress),
              September 2014.

              Gont, F., Will, W., LIU, S., and t. tore, T. Anderson, "Deprecating the
              Generation of IPv6 Atomic Fragments", draft-ietf-6man-
              deprecate-atomfrag-generation-01 (work in progress),
              November 2014. April

              Anderson, T., "SIIT-DC: Dual Translation Mode", draft-
              ietf-v6ops-siit-dc-2xlat-00 (work in progress), January

              Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
              M., and T. Taylor, "Why Operators Filter Fragments and
              What It Implies", draft-taylor-v6ops-fragdrop-02 (work in
              progress), December 2013.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September

   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD
              9, RFC 959, October 1985.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets", BCP
              5, RFC 1918, February 1996.

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, August 1996.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations", RFC
              2663, August 1999.

   [RFC2991]  Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
              Multicast Next-Hop Selection", RFC 2991, November 2000.

   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
              November 2000.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022, January

   [RFC3235]  Senie, D., "Network Address Translator (NAT)-Friendly
              Application Design Guidelines", RFC 3235, January 2002.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC4217]  Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
              October 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              April 2011.

   [RFC6540]  George, W., Donley, C., Liljenstolpe, C., and L. Howard,
              "IPv6 Support Required for All IP-Capable Nodes", BCP 177,
              RFC 6540, April 2012.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.

   [RFC6883]  Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
              Content Providers and Application Service Providers", RFC
              6883, March 2013.

   [RFC6946]  Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
              6946, May 2013.

   [RFC7020]  Housley, R., Curran, J., Huston, G., and D. Conrad, "The
              Internet Numbers Registry System", RFC 7020, August 2013.

   [RFC7230]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Message Syntax and Routing", RFC 7230, June

   [RFC7269]  Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64
              Deployment Options and Experience", RFC 7269, June 2014.

Appendix A.  Complete SIIT-DC IDC topology example

   This figure shows

   Figure 4 attempts to "tie it all together" and show a more complete
   SIIT-DC topology, in order to better demonstrate the beneficial its advantageous
   properties it has.  In particular,
   it tries to highlight the following:

   o  Stateless operation: Any number of SIIT-DC Gateways may be
      deployed side-by side, or indeed anywhere discussed 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 Section 1.  These are discussed 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 more
   detail below.

                       Example SIIT-DC Gateways.

   o  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

   o  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.

   o  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.

                Example data centre topology using SIIT-DC
                   /--------------------------------\ /---------------\
                   | IDC topology

                  /--------------------------------\ /---------------\
                  |          IPv4 Internet         | | IPv6 Internet |
                  \-+----------------------------+-/ \--------+------/
                    |                            |            |
                    | <----------[BGP]---------> |          [BGP]
                    |                            |            |            |
     +-------<>---------+ +---<>---+  |
     |                        BR #1 | | BR #2              |  |
     |        SIIT-DC Gateway 1        | | SIIT-DC Gateway 2  |  |
   |        =================        | | =================  |  |
   |                                 | |                    |  |
   |       Translation Prefix: EAM Table:                   | |                    |  |
     |         2001:db8:46::/96 ==========                   | |                    |  |
     |,2001:db8:12:34::1  | |                    |  |
     |     Static Address Mappings:,2001:db8:12:34::2  | |  Exactly the same  |  |
     | <=> 2001:db8:12:34::1,2001:db8:fe:dc::1  | |  configuration as  |  |
     | <=> 2001:db8:12:34::2,2001:db8:12:34::4  | | SIIT-DC Gateway 1  BR #1 has         |  |
     | <=> 2001:db8:fe:dc::1,2001:db8:fe:dc::e  | |                    |  |
     | <=> 2001:db8:12:34::4                              | |                    |  |
     | [...] XLAT Prefix 2001:db8:46::/96 | |                    |  |
     |                              | |                    |  |
     +--------<2001:db8:46::/96>----+ +-<2001:db8:46::/96>-+  |
                       |                      |               |
                       | <---------[ECMP]---------> <------[ECMP]------> |               |
                       |                      |               |
     /-----------------+----------------------+--\            |
     |         IPv6 data centre IDC network            +----------+
   \-+-----------------------------------+----------/ w/OSPFv3         +------------/
       |                                |
       | Customer Tenant A's server LAN          | Customer Tenant B's server LAN
       | 2001:db8:12:34::/64            | 2001:db8:fe:dc::/64
       |                                |
     |                                   |
       +-- www      ::1 (IPv6+SIIT-DC)  +-- www www-lb ::1 (IPv6+SIIT-DC)
       |                                |
     |                                   +-- file01 ::f:01 (IPv6)
       +-- mta      ::2 (IPv6+SIIT-DC)  +-- web ::80:01 (IPv6-only)
       |   [...]                                |                                   +-- file99 ::f:99 (IPv6)   [...]
       +-- ftp      ::3 (IPv6)          +-- web ::80:99 (IPv6-only)
       |            ::4 (SIIT-DC/Host Agent) (IPv4, via ER)  |
       |                                |         +----+
       +-- app01 ::a:01 (IPv6) (IPv6-only)     \---- ::e | ER | --\
       |   [...]                                  +----+   |
       +-  app99 ::a:99 (IPv6) (IPv6-only)                        |
       |                                  ftp ---/
       +-- db01  ::d:01 (IPv6) (IPv6-only)
       |   [..]
       \-- db99  ::d:99 (IPv6) (IPv6-only)

                                 Figure 7

Appendix B.  Comparison to Other Deployment Approaches

   There are a number of alternative deployment strategies a data centre
   operator may follow.  They each have different properties and helps
   solve a different set of challenges.  This section aims to compare
   the SIIT-DC approach with each of the most common ones, by
   highlighting the benefits and disadvantages of each.

B.1.  IPv4-only

   At the time of writing, IPv4-only operation remains the status quo
   for most operators.  As such, it is well understood and supported.
   An operator can reasonably expect everything to work correctly in an
   IPv4-only environment.

   Benefits of IPv4-only operation compared to SIIT-DC include:

   o  No translation occurs, the end-to-end principle is intact.

   o  Compatible with all common application protocols.

   o  Compatible with IPv4-only devices.

   o  Compatible with IPv4-only application software, without requiring
      a host agent.

   Disadvantages of IPv4-only operation compared to SIIT-DC include:

   o  Does not provide any form of IPv6 connectivity.

   o  Does not alleviate IPv4 address scarcity.

B.2.  IPv4-only + NAPT44

   An operator who would otherwise chose a traditional IPv4-only
   approach, but cannot due to having insufficient public IPv4 addresses
   available, could chose to deploy using a combination of private IPv4
   addresses [RFC1918] and NAPT44 [RFC3022] devices which will translate
   between a smaller number of public IPv4 addresses and the private
   addresses assigned to the servers that provide public services to the

   Benefits of IPv4-only + NAPT44 operation compared to SIIT-DC include:

   o  Compatible with IPv4-only devices.

   o  Compatible with IPv4-only application software, without requiring
      a host agent.

   Disadvantages of IPv4-only + NAPT44 operation compared to SIIT-DC

   o  Does not provide any form of IPv6 availability.

   o  Requires network devices that track all flow state, which may
      create a performance bottleneck and be an easy target for Denial
      of Service attacks.

   o  Limits routing flexibility (prevents closest exit routing), as
      outbound traffic must pass across the same NAPT44 device that
      handled the inbound traffic.

   o  Limited potential for horizontal scaling, as packets cannot be
      load-balanced across multiple NAT devices.

   o  Depending on whether or not the NAPT44 device rewrites source
      addresses in order to attract the return traffic to itself:


      *  Obscures the true source address of the user from the server/
         application, preventing it from e.g. performing geo-location
         lookups, or:

      *  Requires an IPv4 default route to be pointed to the NAPT44
         device, also attracting native traffic that does not need to
         undergo translation.

   In addition, application compatibility is a consideration with both
   NAPT44 and SIIT-DC, but the exact nature depends from application to
   application, so it is hard to objectively quantify if there is a
   clear advantage to either approach here.  Some translation-unfriendly
   application protocols may work without host modifications through the
   use of Application Layer Gateway support in the NAPT44 device (e.g.,
   FTP [RFC0959]), or in the SIIT-DC architecture when a host agent is
   being used [I-D.anderson-v6ops-siit-dc-2xlat].  Other application
   protocols might not work with NAPT44 at all, but will work in the
   SIIT-DC if a host agent is being used (e.g., FTP/TLS [RFC4217]).

   In summary, the most accurate statement would be to say that an
   NAPT44 architecture is more compatible with translation-unfriendly
   protocols than plain SIIT-DC, while SIIT-DC is more compatible than
   NAPT44 if a host agent is used.

   For a more complete discussion of potential issues with running
   NAPT44, see Architectural Implications of NAT [RFC2993].

B.3.  IPv4-only + NAT64

   An operator who would otherwise chose a traditional IPv4-only
   approach, but would in addition like to provide service availability
   for IPv6 end users, could use Stateful NAT64 [RFC6146] to accomplish
   this.  In a sense, this would be the mirror image of an SIIT-DC
   architecture: The infrastructure and servers remains single-stacked,
   while connectivity to the other IP stack is provided through a
   translation system.  Further information about operating Stateful
   NAT64 is found in [RFC7269].

   Note that Stateful NAT64 can be deployed with or without NAPT44.
   With the exception that IPv6 service availability is being provided,
   the discussion in the previous two sections fully applies to an
   IPv4-only environment that includes NAT64.

   Benefits of IPv4-only + NAT64 operation compared to SIIT-DC include:

   o  Compatible with IPv4-only devices.

   o  Compatible with IPv4-only application software, without requiring
      a host agent.

   Disadvantages of IPv4-only + NAT64 operation compared to SIIT-DC

   o  Does not alleviate IPv4 address scarcity (assuming NAPT44 isn't

   o  Requires network devices that track all flow state, which may
      create a performance bottleneck and be an easy target for Denial
      of Service attacks.

   o  Limits routing flexibility (prevents closest exit routing), as
      outbound traffic must pass across the same NAT64 device that
      handled the inbound traffic.

   o  Limited potential for horizontal scaling, as packets cannot be
      load-balanced across multiple NAT devices.

   o  Obscures the true source address of the user from the server/
      application, preventing it from e.g. performing geo-location

   o  The traffic levels on the Stateful NAT64 routers will increase
      over time, in lockstep with the increased deployment of IPv6 in
      the Internet.  For this reason, Section 3.2 of RFC7269 [RFC7269]
      notes that the use of Stateful NAT64 in a data centre environment
      "is only reasonable at an early stage".  With SIIT-DC, the inverse
      is true; the traffic levels on the SIIT-DC Gateways will decrease
      over time, as end users will prefer to use native IPv6 once it is
      available to them.

B.4.  Dual Stack

   Dual Stack [RFC4213] [RFC6883] could be used both with or without
   NAPT44 to handle IPv4.  In general, the benefits and disadvantages
   are equal to the corresponding IPv4-only option, except for the fact
   that Dual Stack does provides IPv6 connectivity.  Therefore, his
   section only lists the benefits and disadvantages which are unique to
   a Dual Stack environment.

   Benefits of Dual Stack operation compared to SIIT-DC include:

   o  No translation occurring, the end-to-end principle is intact
      (assuming NAPT44 isn't used).

   o  Compatible with all common application protocols (assuming NAPT44
      isn't used).

   o  Compatible with IPv4-only devices.

   o  Compatible with IPv4-only application software, without requiring
      a host agent.

   Disadvantages of Dual Stack operation compared to SIIT-DC include:

   o  Does not alleviate IPv4 address scarcity (assuming NAPT44 isn't

   o  Increases the complexity of the infrastructure, as many things
      must done twice (once for IPv4 and once for IPv6).  Examples of
      things that must be duplicated in this manner under Dual Stack
      include: Firewall rules/ACLs, IGP topology, monitoring,

   o  Encourages software developers, systems administrators, etc. to
      build architectures that cannot operate correctly without IPv4.
      This in turn makes it difficult to make use of Dual 4

   Single Stack as a
      short term transitional stage, rather than a near-permanent end

   o  Increases the amount of things that can encounter failures, and
      increases the time IPv6 Operation
      As discussed in Section 1.1, SIIT-DC facilitates an IPv6-only IDC
      network infrastructure.  The only places where IPv4 is absolutely
      required to locate and fix such failures.  This
      reduces reliability.

B.5.  Partial Dual Stack (IPv6-only back-end)

   It is possible to use between the Dual Stack deployment strategy for front-
   end services only.  That is, BRs and the front-end servers (or load
   balancers) that serves public Internet-available services are
   provisioned with both native IPv4 Internet, and between any
      ERs and native IPv6 connectivity on
   their Internet-facing interfaces, while the interfaces facing the
   back-end infrastructure are IPv6 only.  All back-end servers that do
   not communicate directly with Internet clients IPv4-only applications or devices they are IPv6-only.  All
   communication between back-end servers as well serving
      (illustrated here as all traffic between
   the back-end servers and the front-end servers will therefore use
   only IPv6.

   One variation of this approach two tenants' FTP servers).  The figure
      also illustrates how SIIT-DC does not interfere with native IPv6;
      when there is no longer a need to have support IPv4 clients, the BRs
      may be decommissioned without causing any impact to native IPv6

   Stateless Operation
      As discussed in Section 1.2, SIIT-DC operates in a two separate sets of
   front-end servers, where one set has IPv4-only Internet-facing
   interfaces, while stateless
      fashion.  In the other set has IPv6-only Internet-facing
   interfaces.  However, illustration, both sets must have IPv6-only interfaces facing BRs are simultaneously
      advertising (i.e., anycasting) the back-end infrastructure.

   Benefits of Partial Dual Stack operation compared to SIIT-DC include:

   o  No translation occurring, IPv4 Service Address Pool and
      the end-to-end principle is intact.

   o  Compatible with all common application protocols.

   o  Compatible with IPv4-only devices (front-end only).

   o  Compatible with IPv4-only application software (front-end only).

   Disadvantages of Partial Dual Stack operation compared to SIIT-DC

   o  Increases IPv6 Translation Prefix, so incoming traffic from the complexity IPv4
      Internet may arrive at either of the front-end infrastructure, as many
      things must done twice (once BRs, while outgoing IPv6
      traffic destined for IPv4 and once for IPv6).
      Examples endpoints are load balanced between them
      using Equal-Cost Multipath Routing.  No continuous state
      synchronisation between the two BRs occurs.  Should one of things the BRs
      fail, the BGP and OSPF protocols will ensure that must be duplicated in this manner under
      Partial Dual Stack include: Firewall rules/ACLs, IGP topology,
      monitoring, troubleshooting.

   o  Can traffic
      converges on the remaining BR.  Existing sessions will not support be
      disrupted, beyond any IPv4-only devices or application software disruption caused by the BGP/OSPF
      convergence process itself.

   IPv4 Address Conservation
      As discussed in Section 1.3, SIIT-DC conserves the back-end infrastructure.

   In addition, Partial Dual Stack will alleviate IDC operator's
      IPv4 address scarcity
   compared to space.  Even though the normal Dual Stack approach, but two customers in the example
      above have several hundred servers, the majority of them are not quite
      used to run services made available directly from the same
   extent as SIIT-DC.  This is primarily due Internet,
      and therefore do not need to the data centre consume IPv4 addresses.  The IDC
      network infrastructure having to be dual-stacked in order consumes no IPv4 addresses, either.
      Finally, the IPv4 addresses that are assigned to provide native the SIIT-DC
      function as IPv4 addressing Service Address Pools may assigned with 100%
      efficiency, one address at a time; there is no requirement to
      assign multiple addresses to a single customer in a contiguous

   Application support
      As discussed in Section 1.5, as long as the front-end servers, application protocol
      is translation-friendly (illustrated here with HTTP and because the front-end SMTP), it
      will work with SIIT-DC without requiring any special adaptation.
      Furthermore, translation-unfriendly applications (illustrated here
      with FTP) will also work when located behind an ER
      [I-D.ietf-v6ops-siit-dc-2xlat].  Tenant A's FTP server LANs must illustrates
      how an ER may be rounded up located in size to the nearest CIDR boundary
   which may result in IPv4 addresses being unused.  However, depending
   on networking stack of a node, while
      Tenant B's FTP server illustrates how the exact circumstances, this difference in IPv4 address
   consumption between SIIT-DC and Partial Dual Stack ER may be negligible. deployed as a
      network service.  The latter approach enables SIIT-DC to support
      IPv4-only nodes/devices.

Author's Address

   Tore Anderson
   Redpill Linpro
   Vitaminveien 1A
   0485 Oslo

   Phone: +47 959 31 212
   Email: tore@redpill-linpro.com
   URI:   http://www.redpill-linpro.com