IPv6 Operations                                              T. Anderson
Internet-Draft                                            Redpill Linpro
Intended status: Standards Track                        January 25, 2015 Informational                               S. Steffann
Expires: July 29, December 30, 2015                   S.J.M. Steffann Consultancy
                                                           June 28, 2015

                     SIIT-DC: Dual Translation Mode
                   draft-ietf-v6ops-siit-dc-2xlat-00
                   draft-ietf-v6ops-siit-dc-2xlat-01

Abstract

   This document describes an extension of the Stateless IP/ICMP
   Translation for IPv6 Internet Data Centre Environments architecture
   (SIIT-DC), which allows applications, protocols, or nodes that are
   incompatible with IPv6, SIIT-DC and/or Network Address Translation in general to operate
   correctly in an SIIT-DC environment.  This is accomplished by
   introducing a new component called an SIIT-DC Edge Translator, Relay, which
   reverses the translations made by an SIIT-DC Gateway. Border Relay.  The
   application or
   device and/or node is thus provided with seemingly native IPv4 connectivity.
   connectivity that provides end-to-end address transparency.

   The reader is expected to be familiar with the SIIT-DC architecture
   described in I-D.ietf-v6ops-siit-dc.

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 July 29, December 30, 2015.

Copyright Notice

   Copyright (c) 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Edge Translator Relay Description  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Host-Based  Node-Based Edge Translator Relay . . . . . . . . . . . . . . . . . .   5
     3.2.  Network-Based Edge Translator Relay  . . . . . . . . . . . . . . . .   6
   4.  Detailed Topology Example
       3.2.1.  Edge Router "On A Stick"  . . . . . . . . . . . . . .   7
       3.2.2.  Edge Router that Bridges IPv6 Packets . . . . . . . .   9
   5.   8
   4.  Deployment Considerations . . . . . . . . . . . . . . . . . .  12
     5.1.   9
     4.1.  IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . .  12
     5.2.   9
     4.2.  IPv4 MTU  . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.3.  10
     4.3.  IPv4 Identification Header  . . . . . . . . . . . . . . .  12
   6.  Intra-DC  10
   5.  Intra-IDC IPv4 Communication  . . . . . . . . . . . . . . . . .  13
     6.1.  Between IPv4-Only and IPv6-Only Services  . . . .  10
     5.1.  Hairpinning by the SIIT-DC Border Relay . . . .  13
     6.2.  Between Two IPv4-Only Services . . . . .  10
     5.2.  Additional EAMs Configured in Edge Relay  . . . . . . . .  15
   7.  11
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   8.  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   9.  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
     9.1.  13
     8.1.  Address Spoofing  . . . . . . . . . . . . . . . . . . . .  18
   10.  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     10.1.  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     10.2.  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Author's Address  14
   Appendix A.  Examples: Network-Based IPv4 Connectivity  . . . . .  15
     A.1.  Subnet with IPv4 Service Addresses  . . . . . . . . . . .  15
     A.2.  Subnet with Unrouted IPv4 Addresses . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . .  19 . . . . . . . .  17

1.  Introduction

   SIIT-DC [I-D.ietf-v6ops-siit-dc] describes an architecture where
   IPv4-only users can access IPv6-only services through a stateless
   translator called an SIIT-DC Gateway. Border Relay (BR).  This approach has
   certain limitations, however.  In particular, the following cases
   will work poorly or not at all:

   o  Application protocols that do not support NAT (i.e., the lack of
      end-to-end transparency of IP addresses).

   o  Devices which  Nodes that cannot connect to IPv6 networks at all, or which that can
      only connect such networks if they also provide IPv4 connectivity
      (i.e., dual-stacked networks).

   o  Application software which makes use of legacy IPv4-only APIs, or
      otherwise makes assumptions that IPv4 connectivity is available.

   By extending the SIIT-DC architecture with a new component called an
   Edge Translator (ET), Relay (ER), all of the above can be made to work correctly in an
   otherwise IPv6-only network environment using SIIT-DC.

   The purpose of the Edge Translator ER is to reverse the IPv4-to-IPv6 packet
   translations previously done by the SIIT-DC Gateway BR for traffic arriving from IPv4
   clients and forward this as "native" IPv4 to the application software node or device. application.
   In the reverse direction, IPv4 packets transmitted by the application software node or device is
   application are intercepted by the Edge Translator, ER, which will translate translates them to IPv6
   before they are forwarded to the SIIT-DC Gateway, BR, which in turn will reverse the
   translations and forward them to the IPv4 End User.  In
   short, the device client.  The node or
   application software is thus provided with "virtual" IPv4 Internet
   connectivity that retains end-to-end transparency for the IPv4
   addresses.

2.  Terminology

   This document makes use of the following terms:

   SIIT-DC Border Relay (BR)
      A device or a logical function that translates traffic between
      IPv4 clients and IPv6 services.  See [I-D.ietf-v6ops-siit-dc].

   SIIT-DC Edge Translator (ET) Relay (ER)
      A device or logical function that provides "native" IPv4
      connectivity to IPv4-only devices nodes or application software. applications.  It is
      very similar functions in function to an SIIT-DC Gateway,
      the same way as a BR, but is typically located close to the IPv4-only component(s) nodes/
      applications it is supporting rather than on the network border.

   IPv4 Service Address
      A public
      An IPv4 address representing an IPv6 service, with which IPv4-only
      clients will
      communicate.  This communication will be communicates.  It is coupled with an IPv6 Service Address
      using an EAM.  Packets sent to this address is translated to IPv6
      by the
      SIIT-DC Gateway BR and possibly back to IPv4 again by the Edge Translator.

   SIIT-DC Gateway
      A device or a logical function that translates between IPv4 ER, and
      IPv6 vice
      versa in accordance with [I-D.ietf-v6ops-siit-dc].

   Static the opposite direction.

   IPv6 Service Address Mapping
      A bi-directional mapping between
      An IPv6 address assigned to an application, node, or service;
      either directly or indirectly (through an ER).  It is coupled with
      an IPv4 Service Address and using an EAM.  IPv4-only clients
      communicates with the IPv6 Service Address configured through SIIT-DC.

   Explicit Address Mapping (EAM)
      A bi-directional coupling between an IPv4 Service Address and an
      IPv6 Service Address configured in the SIIT-DC Gateway. an BR/ER.  When translating
      between IPv4 and IPv6, the SIIT-DC Gateway BR/ER changes the address fields in the
      translated packet's IP header according to any matching Static Address Mapping. EAM.  The
      EAM algorithm is specified in [I-D.ietf-v6ops-siit-eam].

   Translation Prefix
      An IPv6 prefix into which the entire IPv4 address space is mapped.
      This prefix mapped,
      according to the algorithm in [RFC6052].  The Translation Prefix
      is routed to the SIIT-DC Gateway's BR's IPv6 interface.  It
      is either an Network-Specific Prefix or a Well-Known Prefix as
      specified in [RFC6052].  When translating between
      IPv4 and IPv6,
      the SIIT-DC Gateway an BR/ER will prepend or strip insert/remove the Translation Prefix
      from
      into/from the address fields in the translated packet's IP header,
      unless a Static Address Mapping an EAM exists for the IP address that is being translated.

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

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

   SIIT
      The Stateless IP/ICMP Translation algorithm, as specified in
      question.
      [RFC6145].

   XLAT
      Short for "Translation".  Used in figures to indicate where the Stateless IP/ICMP
      Translation a BR/
      ER uses SIIT [RFC6145] algorithm is used to translate IPv4 packets to IPv6 and vice
      versa.

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

3.  Edge Translator Relay Description

   An Edge Translator (ET) Relay (ER) is at its core an implementation of the Stateless
   IP/ICMP Translation algorithm [RFC6145], with the Static [RFC6145] that supports Explicit
   Address Mapping extension described in Section 5.2 of
   [I-D.ietf-v6ops-siit-dc]. Mappings [I-D.ietf-v6ops-siit-eam].  It provides virtual IPv4
   connectivity for
   application software nodes or devices applications which require this to operate
   correctly in an SIIT-DC environment.

   Inbound

   Packets from the IPv4 packets Internet destined for an IPv4 Service Address
   is first translated to IPv6 by an SIIT-DC Gateway. a BR.  The resulting IPv6 packets are
   subsequently forwarded to the ET handling ER that owns the IPv6 Service Address they
   the translated packets are addressed to.  The ET ER then translates them
   back to IPv4 before forwarding them to the IPv4 application software or
   device. node.
   In the other direction, the exact same translations happen, only in
   reverse.  This process provides end-to-end transparency of IPv4
   addresses.

   An ET ER may handle an arbitrary number of IPv4 IPv4/IPv6 Service Addresses.
   All the Static Address Mappings EAMs configured in the SIIT-DC Gateway(s) BR that involve the IPv4 IPv4/IPv6 Service
   Addresses handled by an ET ER MUST also be
   duplicated present in that ET's the ER's
   configuration.

   An ET ER may be implemented in two distinct ways; as a software-based
   service residing inside an otherwise IPv6-only host, node, or as a network-
   based service that provides an isolated IPv4 network segment to which
   devices which
   nodes that require IPv4 can connect.  In both cases native IPv6
   connectivity may be provided simultaneously with the virtual IPv4
   connectivity.  Thus, dual-stack connectivity is facilitated in case
   the device node or application software support it.

   The choice between a host- node- or network-based ET ER is made on a per-
   service or -device per-node basis.  An arbitrary number of each type of ET ER
   may co-exist in an SIIT-DC architecture.

   This section describes the different approaches and discusses which
   approach fits best for the various use cases.

3.1.  Host-Based  Node-Based Edge Translator

                 Overview of a Host-based Relay

                          A Node-based Edge Translator Relay

    [IPv4 Internet]  [IPv6 Internet]
          |            |
                 +--|--<SIIT-DC GW>--+
    +-----|-----+      |
    | [XLAT] (BR/XLAT) |      |
                 +--|----------------+
    +-----|-----+      |
          |            |      +-----<IPv6-only node/server>----------+
    [IPv6-only data centre IDC network]   |
                 +--|--<IPv6-only server>---------------+
                 |  |                    +----------------+|
       |  +--[ET/XLAT]--AF_INET                      |  /--(ER/XLAT)--AF_INET  Dual-stack  ||
                 |  |
       \-------------------------+                 |    Application ||
                              |  \------------AF_INET6  Software    ||
                              |                    +----------------+|
                              +--------------------------------------+

                                 Figure 1

   A host-based Edge Translator node-based ER is typically implemented as a logical software
   function that runs inside the operating system of a host or
   server. an IPv6 node.  It
   provides software applications running on the same host node with IPv4
   connectivity.  The  Its IPv4 Service Address it handles is SHOULD be considered local, allowing a
   regular local address that allows application software running on the same
   host
   node to use traditional it with IPv4-only API calls, e.g., to create AF_INET
   sockets that listens listen for and accepts accept incoming connections to its IPv4
   Service Address.  An ET could ER may accomplish this by creating an a virtual
   network adapter to which it assigns the IPv4 Service Address and
   points a default IPv4 route.  This approach is similar to the "Bump-
   in-the-Stack" approach discussed in [RFC6535], however it does not
   include an Extension Name Resolver.

   As shown in Figure 1, if the application software supports dual-stack
   operation, IPv6 clients will be able to communicate with it directly
   using native IPv6.  Neither the SIIT-DC Gateway BR nor the ET ER will intercept this
   communication.  Support for IPv6 in the application
   software is however not a
   requirement; the application software may opt not to establish any IPv6
   sockets.  Foregoing IPv6 in this manner will simply preclude
   connectivity to the service from IPv6-only clients; connectivity to
   the service from IPv4 clients (through the
   SIIT-DC Gateway) BR) will continue work in
   the exact same manner in both cases. way.

   The ET ER requires a dedicated IPv6 Service Address for each IPv4
   Service Address it has configured.  The IPv6 network must MUST forward
   traffic to these IPv6 Service Addresses to the host, node, whose operating
   system must MUST in turn forward them to the ET. ER.  This document does not
   attempt to fully explore the multitude of ways this could be
   accomplished, however considering that the IPv6 protocol is designed
   for having multiple addresses assigned to a single node, one
   particularly straight-
   forward straight-forward way would be to assign the ET's ER's IPv6
   Service Addresses as secondary IPv6 addresses on the host node itself so
   that it the upstream router learns of their location using the IPv6
   Neighbor Discovery Protocol [RFC4861].

3.2.  Network-Based Edge Translator

             Overview of a Relay

                     A Basic Network-based Edge Translator Relay

         [IPv4 Internet]  [IPv6 Internet]
               |             |
                   +--|--<SIIT-DC GW>--+
         +-----|-----+       |
         | [XLAT] (BR/XLAT) |       |
                   +--|----------------+
         +-----|-----+       |
               |             |
          [IPv6-only data centre IDC network]
                      |
                   +--|--<ET>--+
                   | [XLAT]    |
                   +--|--------+
                      |
                    [Isolated IPv4-only network segment]
                      |
                   +--|--<IPv4-only server>----+   +--<IPv4-only node/server>--+
               |                    |         +----------------+|
         +-----|-----+   [v4-only]  |         |  \--AF_INET    IPv4-only   ||
         |         | (ER/XLAT)-----[network]--------AF_INET  Application ||
         +-----------+   [segment]  |         |    Software    ||
                                    |         +----------------+|
                                    +---------------------------+

                                 Figure 2

   A network-based Edge Translator ER performs the exact same as a host-
   based ET node-based ER does,
   only that instead of assigning the IPv4 Service Addresses to an
   internal-only virtual network adapter, traffic destined for them are
   forwarded onto a network segment to which hosts nodes that require IPv4
   connectivity connect to.  The ET ER also functions as the default IPv4
   router for the hosts nodes on this network segment.

   Each host node on the IPv4 network segment must MUST acquire and assign an IPv4
   Service Address to a local network interface.  This  While this document
   does not attempt to explore all the various methods by which this can
   could be accomplished, however one relatively straight-forward possibility
   would be to ensure the IPv4 Service Address(es) can be enclosed some examples are provided in an
   IPv4 prefix. Appendix A.

   The ET will then claim one address basic ER illustrated in this prefix for
   itself (used as the IPv4 default router address), and could assign
   the IPv4 Service Address(es) to the host(s) using DHCPv4.  For
   example, if the IPv4 Service Addresses are 192.0.2.26 and 192.0.2.27,
   the ET would configure the address 192.0.2.25/29 on its IPv4-facing
   interface and would add the two IPv4 Service Addresses to its DHCPv4
   pool.

   One disadvantage of this method is that IPv4 communication Figure 2 establishes an IPv4-only network
   segment between
   the IPv4 hosts itself and other services made available through SIIT-DC
   using the method described in Section 6 becomes impossible, if those
   other services are assigned IPv4 Service Addresses that also are
   covered by the same IPv4 prefix (e.g., 192.0.2.28). IPv4-only nodes it serves.  This is because
   fine if the IPv4 nodes will mistakenly believe they it provides IPv4 access have an on-link route to
   the entire prefix, and attempt to resolve the addresses using ARP
   (instead of forwarding them to the ET no support for translation to IPv6).  This
   problem could IPv6
   whatsoever; however be overcome by avoiding assigning IPv4 Service
   Addresses which overlaps with an IPv4 prefix handled by an ET (at the
   expense of wasting some potential IPv4 Service Addresses), or by
   ensuring that if they are only assigned to services which do dual-stack capable, it is would not need to
   communicate with the IPv4 host(s) behind the ET.

   Another way
   be ideal to avoid the problem take away their IPv6 connectivity in this manner.  While
   it is RECOMMENDED to use a private unrouted IPv4
   network that does not encompass the IPv4 Service Addresses as the
   IPv4, and instead assign the IPv4 Service Addresses as secondary
   addresses on the servers.  The ET must then route each IPv4 Service
   Address to its respective server using the server's private on-link
   IPv4 address as the next-hop.  This approach would ensure there are
   no overlaps, but on the other hand it would preclude the use of
   DHCPv4 for assigning the IPv4 Service Addresses, as well as create a
   need to ensure that the IPv4 application software is selecting the
   IPv4 Service Address (as opposed to its private on-link IPv4 address)
   as its source address when initiating outbound connections.

   The basic ET illustrated in Figure 2 establishes an IPv4-only network
   segment behind itself.  This is fine if the devices it provides IPv4
   access have no support for IPv6 whatsoever; however if they are dual-
   stack capable, it is would not be ideal to take away their IPv6
   connectivity.  While it is recommended to use a host-based ET in this
   case, appropriate implementations of a host-based ET might node-based ER in this case, appropriate
   implementations of a node-based ER might not be available for every device.
   node.  If the application protocol in question does not work
   correctly in a NAT environment, standard SIIT-DC cannot be used
   either.  Thus,
   either, which leaves a network-based ET ER is the only remaining
   solution.  The operator could avoid breaking following subsections contains examples on how the hosts' ER
   could be implemented in a way that provides IPv6 connectivity for
   dual-stack capable nodes.

3.2.1.  Edge Router "On A Stick"

                  A Network-based Edge Relay "On A Stick"

       [IPv4 Internet]  [IPv6 Internet]
             |             |
       +-----|-----+       |
       | (BR/XLAT) |       |
       +-----|-----+       |
             |             |
        [IPv6-only IDC network]
          |
          |  +-------------+
          |  |  _IPv6_     |
          |  | /      \    |
          +====  (ER/XLAT) |
          |  | \_    _/    |
          |  |   IPv4      |          +--<Dual stack node/server>--+
          |  +-------------+          |          +----------------+|
          |                           |  /---AF_INET  Dual-stack  ||
        [Dual-stack network segment]----<        |    Application ||
                                      |  \--AF_INET6  Software    ||
                                      |          +----------------+|
                                      +----------------------------+

                                 Figure 3

   The ER "On A Stick" approach illustrated in Figure 3 ensures that the
   dual-stack capable node retains native IPv6 connectivity by
   connecting the ET's ER's IPv4 and IPv6 interfaces to the same network
   segment, or alternatively by using a single dual-stacked interface instead.  The
   latter alternative is shown in Figure 3.  This could be thought of as
   an "ET on a stick". interface.
   Native IPv6 traffic between the IDC network and the hosts
   will bypass node bypasses the ET entirely.
   ER entirely, while IPv4 traffic from the hosts node will be routed directly
   to the ET ER (because it's their it acts as its default IPv4 router),
   and where it is
   translated to IPv6 before its being transmitted to the upstream default
   IPv6 router.  The ET ER could attract inbound traffic to its the IPv6
   Service Addresses by responding to the upstream router's IPv6
   Neighbor Discovery [RFC4861] messages for them.

3.2.2.  Edge Router that Bridges IPv6 Packets

           A Network-based Edge Translator "on a stick" Relay containing an IPv6 Bridge

       [IPv4 Internet]  [IPv6 Internet]
             |             |
                     +--|--<SIIT-DC GW>--+
       +-----|-----+       |
       | [XLAT] (BR/XLAT) |       |
                     +--|----------------+
       +-----|-----+       |
             |             |
        [IPv6-only data centre IDC network]
                   |
       +-----------|--------------+
       |  +--<ET>------+
                        |  |  ____      |      ____/ \_IPv6_       |
       |     /             \      |
                        +====   [XLAT]  |
                        |
       | \____/ (IPv6 Bridge)  (ER/XLAT) |
       |     \____   _    _/      |
       |          \ / IPv4        |  +------------+
                        |
                      [Dual-stack network segment]
                        |
                     +--|--<Dual-stack server>----+
                     |   +--<Dual stack node/server>--+
       +-----------|--------------+   |          +----------------+|
                   |  +---AF_INET                  |  /---AF_INET  Dual-stack  ||
                     |  |
        [Dual-stack network segment]----<        |    Application ||
                                      |  \--AF_INET6  Software    ||
                                      |          +----------------+|
                                      +----------------------------+

                                 Figure 3

   Yet another variation would be to implement the ET so that it 4

   The ER illustrated in Figure 4 will transparently passes bridge IPv6 traffic frames
   between its downstream and upstream
   network ports unmodified, e.g., using Layer-2 bridging.  Packets sent
   to its and downstream interfaces.  IPv6 packets
   addressed the ER's own IPv6 Service Addresses from the upstream IDC
   network are intercepted (e.g, (e.g., by responding to IPv6 Neighbor
   Discovery [RFC4861] messages for them) and routed through the
   translation function, and function before being forwarded out its downstream interface.
   interface as IPv4 packets.  The downstream network segment is thus
   becomes dual-stacked.  This model is shown in Figure
   4.

                A Transparent Network-based Edge Translator

                     [IPv4 Internet]   [IPv6 Internet]
                        |                         |
                     +--|--<SIIT-DC GW>--+        |
                     | [XLAT]            |        |
                     +--|----------------+        |
                        |                         |
                      [IPv6-only data centre network]
                        |
                     +--|--<Edge Translator>--+
                     |  |\_____________       |
                     |  |              \      |
                     | [Bridged IPv6] [XLAT]  |
                     |  | _____________/      |
                     |  |/                    |
                     +--|---------------------+
                        |
                      [Dual-stack network segment]
                        |
                     +--|--<Dual-stack server>----+
                     |  |       +----------------+|
                     |  +---AF_INET  Dual-stack  ||
                     |  |       |    Application ||
                     |  \--AF_INET6  Software    ||
                     |          +----------------+|
                     +----------------------------+

                                 Figure 4

4.  Detailed Topology Example  Deployment Considerations

4.1.  IPv6 Path MTU

   The following figure shows how an application (that is presumably
   incompatible with standard SIIT-DC) is being made available to IPv6 Path MTU between the
   IPv4 Internet on ER and the IPv4 address 192.0.2.4.  The application BR will typically be
   able to know that this is its local address and thus be able to
   provide correct references to it in application payload.

   The figure also shows how larger
   than the same application default value defined in Section 4 of [RFC6145] (1280), as
   it will typically contained within a single administrative domain.
   Therefore, it is available over IPv6
   on its RECOMMENDED that the IPv6 Service Address 2001:db8:12:34::3.  This is included Path MTU configured in
   order to illustrate how native IPv6 connectivity the
   ER is not impacted by raised accordingly.  It is RECOMMENDED that the Edge Translator, ER and also to illustrate how the address assigned BR
   use identical configured IPv6 Path MTU values.

4.2.  IPv4 MTU

   In order to the ET (2001:db8:12:34::4) is separate from the primary avoid IPv6
   address of fragmentation, an ER SHOULD ensure that the server.  It
   IPv4 MTU used by applications or nodes is however important equal to note the configured
   IPv6 Path MTU - 20, so that an maximum-sized IPv4 packet can fit in
   an unfragmented IPv6 packet.  This ensures that the application may
   do its part in question does not have to be dual-stack capable avoiding IP-level fragmentation from occurring, e.g.,
   by segmenting/fragmenting outbound packets at
   all.  IPv4-only applications would also be able to operate behind an
   ET in the exact same manner.

   Note that application layer,
   and advertising the maximum size its peer may use for inbound packets
   (e.g., through the figure below use of the TCP MSS option).

   A node-based ER could be considered accomplish this by configuring this MTU value
   on the virtual network adapter, while a more detailed view
   of Customer A's FTP server from network-based ER could do so
   by advertising the example topology figure in
   Appendix A MTU to its downstream nodes using the DHCPv4
   Interface MTU Option [RFC2132].

4.3.  IPv4 Identification Header

   If the generation of [I-D.ietf-v6ops-siit-dc].  Both figures intentionally
   use IPv6 Atomic Fragments is disabled, the exact same example IP addresses and prefixes.

              SIIT-DC Host Architecture with Edge Translation

             +-------------------+         +----------------+
             | IPv6-capable user |         | IPv4-only user |
             | ================= |         | ============== |
             |                   |         |                |
             +-<2001:db8::ab:cd>-+         +-<203.0.113.50>-+
                 |                                  |
              (the value of
   the IPv4 Identification header will be lost during the translation.
   Conversely, enabling the generation of IPv6 internet)         (the Atomic Fragments will
   ensure that the IPv4 Internet)
                 |                                  |
                 |        +------------------<192.0.2.0/24>-+
                 |        |                                 |
                 |        |         SIIT-DC Gateway         |
                 |        |         ===============         |
                 |        |                                 |
                 |        |       Translation Prefix:       |
                 |        |         2001:db8:46::/96        |
                 |        |                                 |
                 |        |     Static Address Mapping:     |
                 |        | 192.0.2.4 <=> 2001:db8:12:34::4 |
                 |        |                                 |
                 |        +--------------<2001:db8:46::/96>-+
                 |                               |
                (the IPv6-only data centre network)
                 |                               |
           +--<2001:db8:12:34::3>-------<2001:db8:12:34::4>---+
           |     |                               |            |
           |     |          IPv6-only server     |            |
           |     |          ================     |            |
           |     |                               |            |
           |     |        +-------------<2001:db8:12:34::4>-+ |
           |     |        |                                 | |
           |     |        |         Edge Translator         | |
           |     |        |         ===============         | |
           |     |        |                                 | |
           |     |        |       Translation Prefix:       | |
           |     |        |         2001:db8:46::/96        | |
           |     |        |                                 | |
           |     |        |     Static Address Mapping:     | |
           |     |        | 192.0.2.4 <=> 2001:db8:12:34::4 | |
           |     |        |                                 | |
           |     |        +---------------------<192.0.2.4>-+ |
           |     |                                   |        |
           | +-[2001:db8:12:34::3]--------------[192.0.2.4]-+ |
           | |      AF_INET6                      AF_INET   | |
           | |                                              | |
           | |           Dual-stacked application           | |
           | |                                              | |
           | +----------------------------------------------+ |
           +--------------------------------------------------+
                                 Figure 5

5.  Deployment Considerations

5.1.  IPv6 Path MTU

   The Identification Header will carried end-to-end.
   Note that for this to work bi-directionally, IPv6 Path MTU between Atomic Fragment
   generation MUST be enabled on both the Edge Translator BR and the SIIT-DC Gateway
   will typically be larger than ER.

   Apart from certain diagnostic tools, there are few (if any)
   application protocols that make use of the default IPv4 Identification
   header.  Therefore, the loss of the IPv4 Identification value defined will
   therefore generally not cause any problems.

   IPv6 Atomic Fragments and their impact on the IPv4 Identification
   header is further discussed in Section 4 4.9.2 of [RFC6145] (1280), as it will typically contained within a single
   administrative domain.  Therefore, it
   [I-D.ietf-v6ops-siit-dc].

5.  Intra-IDC IPv4 Communication

   Although SIIT-DC is recommended that primarily intended to facilitate communication
   between IPv4-only nodes on the IPv6
   Path MTU configured Internet and services located in an
   IPv6-only IDC network, an IPv4-only node or application located
   behind an ER might need to communicate with other nodes or services
   in the ET is raised accordingly.  It is
   RECOMMENDED that the ET and IDC.  The IPv4-only node or application will need to so
   through the SIIT-DC Gateway use identical
   configured IPv6 Path MTU values.

5.2.  IPv4 MTU

   In order ER, as it will typically be incapable to avoid contact IPv6 fragmentation, an Edge Translator should
   ensure that the IPv4 MTU used
   destinations directly.  The following subsections discusses various
   methods on how to facilitate such communication.

5.1.  Hairpinning by applications or hosts the SIIT-DC Border Relay
   If the BR supports hairpinning as described in Section 4.2 of I-D
   .ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam], the easiest solution
   is equal to make the configured IPv6 Path MTU - 20, so target service available through SIIT-DC in the normal
   way, that is, by provisioning an maximum-sized IPv4
   packet can fit in EAM to the BR that assigns an unfragmented IPv4
   Service Address with the target service's IPv6 packet. Service Address.

   This ensures that allows the IPv4-only node or application may do its part in avoiding IP-level fragmentation from
   occurring, e.g., by segmenting/fragmenting outbound to transmit packets at the
   application layer, and advertising the maximum size its peer may use
   destined for inbound packets (e.g., through the use of the TCP MSS option).

   A host-based ET could accomplish this by configuring this MTU value
   on target service's IPv4 Service Address, which the virtual network adapter, while ER
   will then translate to a network-based ET could do so corresponding IPv4-converted IPv6 address by advertising
   inserting the MTU to its downstream hosts using Translation Prefix [RFC6052].  When this IPv6 packet
   reaches the DHCPv4
   Interface MTU Option [RFC2132].

5.3.  IPv4 Identification Header

   If BR, it will be hairpinned and transmitted back to the generation of
   target service's IPv6 Atomic Fragments is disabled, Service Address (where it could possibly pass
   through another ER before reaching the value of target service).  Return
   traffic from the IPv4 Identification header target service will be lost during the translation.
   Conversely, enabling hairpinned in the generation of IPv6 Atomic Fragments will
   ensure that same
   fashion.

                     Hairpinned IPv4-IPv4 packet flow

   +-[Pkt#1: IPv4]-+             +--[Pkt#2: IPv6]-------------+
   | SRC 192.0.2.1 |  (XLAT#1)   | SRC 2001:db8:a::           |
   | DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:46::192.0.2.2 |---\
   +---------------+             +----------------------------+   |
                                                                (XLAT#2)
   +-[Pkt#4: IPv4]-+             +--[Pkt#3: IPv6]-------------+ ( @ BR )
   | SRC 192.0.2.1 |   (XLAT#3)  | SRC 2001:db8:46::192.0.2.1 |   |
   | DST 192.0.2.2 |<--(@ ER B)--| DST 2001:db8:b::           |<--/
   +---------------+             +----------------------------+

                                 Figure 5

   Figure 5 illustrates the IPv4 Identification Header will carried end-to-end.
   Note that for this to work bi-directionally, IPv6 Atomic Fragment
   generation must be enabled on both flow of a hairpinned packet sent from the SIIT-DC Gateway(s) and on
   IPv4-only node/app behind ER A towards an IPv6-only node/app behind
   ER B. ER A is configured with the
   Edge Translator. EAM {192.0.2.1,2001:db8:a::}, ER B
   with {192.0.2.2,2001:db8:b::}. The BR is configured with both EAMs,
   and supports hairpinning.  Note that apart from certain diagnostic tools, there are few (if any)
   application protocols that make use of the IPv4 Identification
   header.  Therefore, if the loss of target service had not
   been located behind an ER, the IPv4 Identification value will
   therefore generally third and final translation (XLAT#3)
   would not cause any problems.

   IPv6 Atomic Fragments have happened, i.e., the target service/node would have
   received and their impact on responded to packet #3 directly.

   If the IPv4-only nodes/services do not need connectivity with the
   public IPv4 Identification
   header is further discussed in Section 4.8.2 of
   [I-D.ietf-v6ops-siit-dc].

6.  Intra-DC Internet, private IPv4 Communication

   While SIIT-DC is primarily intended addresses [RFC1918] could be used
   as their IPv4 Service Addresses in order to facilitate communication
   between IPv4-only nodes on conserve the Internet and services hosted IDC
   operator's pool of public IPv4 addresses.

5.2.  Additional EAMs Configured in an
   IPv6-only network, it is also possible to facilitate communication
   between an IPv4-only service or application running behind an Edge
   Translator and another service/application made available over IPv4
   through SIIT-DC.  This other service/application may be a IPv6-only
   service, Relay

   If the BR does not support hairpinning, or it if the hairpinning
   solution is not desired for some other reason, intra-IDC IPv4 traffic
   may also be an IPv4-only service running behind
   another ET.

   Facilitating such communication requires that another Static Address
   Mapping is configured in facilitated by configuring additional EAMs on the ET (one ER for each
   service it wants the IPv4-only node or application needs to communicate to).  If there are two ETs involved, both of them must be
   configured in with.
   This makes the same fashion for bi-directional communication to
   work. IPv6 traffic between the ER and the target service's
   IPv6 Service Address follow the direct path through the IPv6 network.
   The following two subsections contain examples traffic does not pass the BR, which means that
   demonstrate how this may be set up.

   Note that for solution
   might yield better latency than the intra-DC communication described hairpinning approach.

   The additional EAM configured in this section, the SIIT-DC Gateway is not involved at all.  Therefore there is no
   requirement that ER consists of the Static target's IPv6
   Service Address Mappings in question are also
   configured on the SIIT-DC Gateway.  It is also possible to use
   private [RFC1918] and an IPv4 addresses, in order to reduce Service Address.  The IPv4-only node or
   application will contact the need for
   publicly routable target's assigned IPv4 addresses.  However, if Service Address
   using its own IPv4 Service Address as the IPv4-only
   application(s) are also source.  The ER will then
   proceed to be made available translate this to the IPv4 Internet
   through an SIIT-DC Gateway, it is highly recommended that IPv6 packet with the Static local
   application/node's own IPv6 Service Address Mappings configured in the ET match those configured in as source and the
   SIIT-DC Gateway.  Otherwise one end up in target
   service's IPv6 Service Address as the situation where a
   service is reached using different IPv4 addresses depending on
   whether one connects destination, and forward this
   to it from the IPv4 Internet or IPv6 network.  Replies from another
   IPv4-only application residing in the same data centre.  While it may
   still work, target service will undergo
   these translations in reverse.

   If the overall architecture gets significantly more complex.

   Finally, if both services/applications support IPv6, it target service is highly
   recommended also located behind another ER, that IPv6 is used for all internal communications.  The
   approach described in this section should only other
   ER MUST also be used if one or both
   of the services or applications only supports IPv4, making native
   IPv6 communication impossible.

6.1.  Between IPv4-Only and IPv6-Only Services

   This section demonstrates how an IPv4-only service/application "A"
   running behind an ET can communicate provisioned with an IPv6-only service "B".

                 Intra-DC additional EAM that contains the
   origin IPv4-only application/node's IPv4 and IPv6 Service Addresses.
   Otherwise, the target service's ER will be unable to IPv6-only Overview

      /--------------------------------------\ translate the
   source address of the incoming packets.

                   Non-hairpinned IPv4-IPv4 packet flow

            +-[Pkt#1: IPv4]-+             +--[Pkt#2: IPv6]---+
            |    IPv6-only data centre network SRC 192.0.2.1 |
      \-+----------------------------------+-/  (XLAT#1)   | SRC 2001:db8:a:: |
            | DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:b:: |
   +--<2001:db8:6::>----------------+ +--<2001:db8:7::>----------------+
            +---------------+             +------------------+
                                                   |
            +-[Pkt#3: IPv4]-+                      |
            | SRC 192.0.2.1 |        (XLAT#2)      |
            |
   |    |  IPv6-only server A       | |    |  IPv6-only server B       |
   |    |  ==================       | |    |  ==================       |
   |    |                           | |    |                           |
   |+-<2001:db8:6::>---------------+| |+-[2001:db8:7::]---------------+|
   ||                              || ||    AF_INET6                  ||
   ||      Edge Translator A       || ||                              ||
   ||      =================       || ||   IPv6-only application B    ||
   ||                              || |+------------------------------+|
   ||   Static Address Mappings:   || +--------------------------------+
   ||  192.0.2.6 <=> 2001:db8:6::  ||
   ||  192.0.2.7 <=> 2001:db8:7::  ||
   ||                              ||
   |+-<192.0.2.6>------------------+|
   |       |                        |
   |+-[192.0.2.6]------------------+|
   ||   AF_INET                    ||
   ||                              ||
   ||   IPv4-only application A    ||
   |+------------------------------+|
   +--------------------------------+ DST 192.0.2.2 |<-------(@ ER B)------/
            +---------------+

                                 Figure 6

   In this example,

   Figure 6 illustrates the flow of a packet carrying intra-IDC IPv4
   traffic between two IPv4-only application on server "A" is listening
   on nodes/applications that are both
   located behind ERs.  Both ER A and ER B are configured with two EAMs:
   {192.0.2.1,2001:db8:a::} and {192.0.2.2,2001:db8:b::}. The packet
   will follow the IPv4 address 192.0.2.6, which is made available to regular routing path through the IPv6
   network on IDC network;
   the IPv6 address 2001:db8:6:: (by BR is not involved and the ET). packet will not be hairpinned.

   The IPv6-only
   application on server "B" above approach is only listening not mutually exclusive with the hairpinning
   approach described in Section 5.1: If both EAMs above are also
   configured on the IPv6 address
   2001:db8:7::, BR, both 192.0.2.1 and has no knowledge of IPv4.

   In order to facilitate communication between 192.0.2.2 would be reachable
   from other IPv4-only services/nodes using the two application,
   another Static Address Mapping must hairpinning approach.
   They would also be configured in reachable from the ET on server
   "A".  This provides an IPv4 address (192.0.2.7) Internet.

   Note that if the IPv4-only
   application can communicate with, which represents the target service in this example was not located
   behind an ER, but instead was a native IPv6 address
   used by application "B" (2001:db8:7::).

   The following figure shows service listening on
   2001:db8:b::, the packet translations second translation step by step, for
   a packet sent by in Figure 6 would not
   occur; the IPv4-only application "A" target service would receive and respond to packet #2
   directly.

   As with the IPv6-only
   application "B".  For traffic in hairpinning approach, if the opposite direction, you may read IPv4-only nodes/services do
   not need connectivity to/from the figure from public IPv4 Internet, private IPv4
   addresses [RFC1918] could be used as their IPv4 Service Addresses.
   Alternatively, in the bottom up and swap case where the Src/Dst addresses.

                Intra-DC IPv4-only to IPv6-only Packet Flow

       (IPv4-only application A)  --\
         |                          |
        Src 192.0.2.6               |
        Dst 192.0.2.7               | Packet forwarding/translations
         |                          | happening inside server A
         V                          |
       [SIIT-DC ET A]               |
         |                        --/
         |                        --\
        Src 2001:db8:6::            | Actual IPv6 packets routed
        Dst 2001:db8:7::            | through the IPv6 network
         |                        --/
         V
       (IPv6-only application B)

                                 Figure 7

6.2.  Between Two IPv4-Only Services

   This section demonstrates how an IPv4-only service/application "A"
   running behind an ET can communicate with an IPv4-only service/
   application "B" running behind another ET.

                 Intra-DC IPv4-only to IPv6-only Overview

      /--------------------------------------\
      |    IPv6-only data centre network     |
      \-+----------------------------------+-/
        |                                  |
        |                                  |
   +--<2001:db8:8::>----------------+ +--<2001:db8:9::>----------------+
   |    |                           | |    |                           |
   |    |  IPv6-only server A       | |    |  IPv6-only server B       |
   |    |  ==================       | |    |  ==================       |
   |    |                           | |    |                           |
   |+-<2001:db8:8::>---------------+| |+-<2001:db8:9::>---------------+|
   ||                              || ||                              ||
   ||      Edge Translator A       || ||      Edge Translator B       ||
   ||      =================       || ||      =================       ||
   ||                              || ||                              ||
   ||   Static Address Mappings:   || ||   Static Address Mappings:   ||
   ||  192.0.2.8 <=> 2001:db8:8::  || ||  192.0.2.8 <=> 2001:db8:8::  ||
   ||  192.0.2.9 <=> 2001:db8:9::  || ||  192.0.2.9 <=> 2001:db8:9::  ||
   ||                              || ||                              ||
   |+-<192.0.2.8>------------------+| |+-<192.0.2.9>------------------+|
   |       |                        | |       |                        |
   |+-[192.0.2.8]------------------+| |+-[192.0.2.9]------------------+|
   ||   AF_INET                    || ||   AF_INET                    ||
   ||                              || ||                              ||
   ||   IPv4-only application A    || ||   IPv4-only application B    ||
   |+------------------------------+| |+------------------------------+|
   +--------------------------------+ +--------------------------------+

                                 Figure 8

   In this example, the IPv4-only application on server "A" target service is listening on native
   IPv6, the target's assigned IPv4 address 192.0.2.8, which is made available to the IPv6
   network on the IPv6 address 2001:db8:8:: (by the ET).  In the same
   fashion, Service Address has only local
   significance behind the IPv4-only application on server "B" is listening on ER.  It could therefore be assigned from the
   IPv4 address 192.0.2.9 Service Continuity Prefix [RFC7335].

6.  Acknowledgements

   The author would like to especially thank the authors of 464XLAT
   [RFC6877]: Masataka Mawatari, Masanobu Kawashima, and is made available Cameron Byrne.
   The architecture described by its ET on the IPv6
   address 2001:db8:9::.

   In order this document is merely an adaptation
   of their work to facilitate communication between the two application, a
   second Static Address Mapping must be configured in data centre environment, and could not have
   happened without them.

   The author would like also to thank the ET on both
   servers. following individuals for
   their contributions, suggestions, corrections, and criticisms: Fred
   Baker, Tobias Brox, Ray Hunter, Shucheng LIU (Will), Andrew
   Yourtchenko.

7.  IANA Considerations

   This provides each application with an IPv4 address that
   represents the other application.  Thus bi-directional communication
   between draft makes no request of the two applications can commence. IANA.  The following figure shows RFC Editor may remove
   this section prior to publication.

8.  Security Considerations

   This section discusses security considerations specific to the packet translations step by step, for
   a packet sent by use of
   an ER.  See the IPv4-only application "A" Security Considerations section in
   [I-D.ietf-v6ops-siit-dc] for additional security considerations
   applicable to the IPv4-only
   application "B".  For traffic SIIT-DC architecture in general.

8.1.  Address Spoofing
   If the opposite direction, you may read ER receives an IPv4 packet from the figure application/node from a
   source address it does not have an EAM for, both the bottom up source and swap the Src/Dst addresses.

                Intra-DC IPv4-only
   destination addresses will be rewritten according to IPv4-only Packet Flow

       (IPv4-only application A) --\
         |                         |
        Src 192.0.2.8              |
        Dst 192.0.2.9              | Packet forwarding/translations
         |                         | happening inside server A
         V                         |
       [SIIT-DC ET A]              |
         |                       --/
         |                       --\
        Src 2001:db8:8::           | Actual IPv6 packets [RFC6052].
   After undergoing the reverse translation in the BR, the resulting
   IPv4 packet routed
        Dst 2001:db8:9::           | through to the IPv6 IPv4 network
         |                       --/
         V                       --\
       [SIIT-DC ET B]              |
         |                        |
        Src 192.0.2.8             | Packet forwarding/translations
        Dst 192.0.2.9             | happening inside server B
         |                        |
         V                        |
       (IPv4-only application B) --/

                                 Figure 9

7.  Acknowledgements will have a spoofed IPv4
   source address.  The author ER SHOULD therefore ensure that ingress
   filtering [RFC2827] is used on the ER's IPv4 interface, so that such
   packets are immediately discarded.

   If the ER receives an IPv6 packet with both the source and
   destination address equal to one of its local IPv6 Service Addresses,
   the resulting packet would like appear to the IPv4-only application/node
   as locally generated, as both the source address and the destination
   address will be the same address.  This could trick the application
   into believing the packet came from a trusted source (itself).  To
   prevent this, the ER SHOULD discard any received IPv6 packets that
   have a source address that is either 1) equal to any of its local
   IPv6 Service Addresses, or 2) after translation from IPv6 to IPv4,
   equal to any of its local IPv4 Service Addresses.

9.  References

9.1.  Normative References

   [I-D.ietf-v6ops-siit-dc]
              Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
              IPv6 Data Centre Environments", draft-ietf-v6ops-siit-
              dc-00 (work in progress), December 2014.

   [I-D.ietf-v6ops-siit-eam]
              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.

9.2.  Informative References

   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              converting network protocol addresses to 48.bit Ethernet
              address for transmission on Ethernet hardware", STD 37,
              RFC 826, November 1982.

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

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

   [RFC6535]  Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
              Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.

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

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation", RFC
              6877, April 2013.

   [RFC7335]  Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335,
              August 2014.

Appendix A.  Examples: Network-Based IPv4 Connectivity

A.1.  Subnet with IPv4 Service Addresses
   One relatively straight-forward way to especially thank provide IPv4 connectivity
   between the authors of 464XLAT
   [RFC6877]: Masataka Mawatari, Masanobu Kawashima, ER and Cameron Byrne.
   The architecture described by this document the IPv4 node(s) it serves is merely an adaptation
   of their work to ensure the IPv4
   Service Address(es) can be enclosed within a data centre environment, and could not have
   happened without them. larger IPv4 prefix.  The author would like also to thank the following individuals
   ER may then claim one address in this prefix for
   their contributions, suggestions, corrections, itself, and criticisms: Fred
   Baker, Tobias Brox, Ray Hunter, Shucheng LIU (Will), Andrew
   Yourtchenko.

8.  IANA Considerations

   This draft makes no request of the IANA. use it
   to provide an IPv4 default router address.  The RFC Editor ER may remove
   this section prior then proceed
   to publication.

9.  Security Considerations

   This section discusses security considerations specific assign the IPv4 Service Address(es) to its downstream node(s)
   using DHCPv4 [RFC2131].  For example, if the use of
   an Edge Translator.  See IPv4 Service Addresses
   are 192.0.2.26 and 192.0.2.27, the Security Considerations section in
   [I-D.ietf-v6ops-siit-dc] for additional security considerations
   applicable to ER would configure the SIIT-DC architecture in general.

9.1.  Address Spoofing

   If address
   192.0.2.25/29 on its IPv4-facing interface and would add the ET receives an two IPv4 packet from
   Service Addresses to its DHCPv4 pool.

   One disadvantage of this method is that IPv4 communication between
   the application from a
   different source address than IPv4 node(s) behind the one it has a Static Address Mapping
   for, ER and other services made available
   through SIIT-DC becomes impossible, if those other services are
   assigned IPv4 Service Addresses that also are covered by the same
   IPv4 prefix (e.g., 192.0.2.28).  This happens because the both IPv4 nodes
   will mistakenly believe they have an on-link route to the source entire
   prefix, and destination attempt to resolve the addresses will be rewritten
   according using ARP [RFC0826],
   instead of sending them to [RFC6052].  After undergoing the reverse ER for translation in
   the SIIT-DC Gateway, the resulting IPv4 packet routed to the IPv6.  This
   problem could however be overcome by avoiding assigning IPv4
   network will have a spoofed Service
   Addresses which overlaps with an IPv4 source address.  The ET should
   therefore ensure that ingress filtering (cf. BCP38 [RFC2827]) is used
   on prefix handled by an ER (at the ET's
   expense of wasting some potential IPv4 interface, so Service Addresses), or by
   ensuring that such packets are immediately
   discarded.

   If the ET receives an overlapping IPv6 packet Service Addresses are only
   assigned to services which do not need to communicate with both the source and
   destination address equal IPv4
   node(s) behind the ER.  A third way to avoid this problem is
   discussed in Appendix A.2.

A.2.  Subnet with Unrouted IPv4 Addresses

   In order to avoid the one it has problem discussed in Appendix A.1, a Static Address Mapping
   for, private
   unrouted IPv4 network that does not encompass the resulting packet would appear IPv4 Service
   Address(es) could be used to provide connectivity between the application as locally
   generated, as both the source address ER and
   the destination address
   will be the same address IPv4-only node(s) it serves.  An IPv4-only node must then assign
   its IPv4 Service Address as secondary local address, while the one configured on ER
   routes each of the virtual IPv4
   interface.  This could trick the application into thinking this
   packet came from a trusted source, and give elevated privileges
   accordingly.  To prevent this, the ET should discard any received
   IPv6 packets that have a source address that is equal either Service Addresses to
   either the its assigned node using
   that node's private on-link IPv4 (after undergoing [RFC6052] translation) or the IPv6 address in as the Static Address Mapping.

10.  References

10.1.  Normative References

   [I-D.ietf-v6ops-siit-dc]
              tore, t., "SIIT-DC: Stateless IP/ICMP Translation for IPv6
              Data Centre Environments", draft-ietf-v6ops-siit-dc-00
              (work next-hop.  This
   approach would ensure there are no overlaps with IPv4 Service
   addresses elsewhere in progress), December 2014.

   [RFC2119]  Bradner, S., "Key words for the infrastructure, but on the other hand it
   would preclude the use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

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

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of DHCPv4 [RFC2131] for assigning the IPv4
   Service Addresses.

   This approach creates a need to ensure that the IPv4 application is
   selecting the IPv4 Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

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

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation", RFC
              6877, April 2013.

Author's (as opposed to its private on-link
   IPv4 address) as its source address when initiating outbound
   connections.  This could be accomplished by altering the Default
   Address Selection Policy Table [RFC6724] on the IPv4 node.

Authors' Addresses

   Tore Anderson
   Redpill Linpro
   Vitaminveien 1A
   0485 Oslo
   Norway

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

   Sander Steffann
   S.J.M. Steffann Consultancy
   Tienwoningenweg 46
   Apeldoorn, Gelderland  7312 DN
   The Netherlands

   Email: sander@steffann.nl