doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc7756.txt b/doc/rfc/rfc7756.txt
new file mode 100644
index 0000000..6b463dd
--- /dev/null
+++ b/doc/rfc/rfc7756.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       T. Anderson
+Request for Comments: 7756                                Redpill Linpro
+Category: Informational                                      S. Steffann
+ISSN: 2070-1721                              S.J.M. Steffann Consultancy
+                                                           February 2016
+
+
+      Stateless IP/ICMP Translation for IPv6 Internet Data Center
+             Environments (SIIT-DC): Dual Translation Mode
+
+Abstract
+
+   This document describes an extension of the Stateless IP/ICMP
+   Translation for IPv6 Internet Data Center Environments (SIIT-DC)
+   architecture, which allows applications, protocols, or nodes that are
+   incompatible with IPv6 and/or Network Address Translation to operate
+   correctly with SIIT-DC.  This is accomplished by introducing a new
+   component called an SIIT-DC Edge Relay, which reverses the
+   translations made by an SIIT-DC Border Relay.  The application and/or
+   node is thus provided with seemingly native IPv4 connectivity that
+   provides end-to-end address transparency.
+
+   The reader is expected to be familiar with the SIIT-DC architecture
+   described in RFC 7755.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7756.
+
+
+
+
+
+
+
+
+
+
+
+Anderson & Steffann           Informational                     [Page 1]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 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
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Edge Relay Description  . . . . . . . . . . . . . . . . . . .   5
+     3.1.  Node-Based Edge Relay . . . . . . . . . . . . . . . . . .   6
+     3.2.  Network-Based Edge Relay  . . . . . . . . . . . . . . . .   7
+       3.2.1.  Edge Relay "on a Stick" . . . . . . . . . . . . . . .   8
+       3.2.2.  Edge Relay That Bridges IPv6 Packets  . . . . . . . .   9
+   4.  Deployment Considerations . . . . . . . . . . . . . . . . . .   9
+     4.1.  IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . .   9
+     4.2.  IPv4 MTU  . . . . . . . . . . . . . . . . . . . . . . . .  10
+     4.3.  IPv4 Identification Header  . . . . . . . . . . . . . . .  10
+   5.  Intra-IDC IPv4 Communication  . . . . . . . . . . . . . . . .  10
+     5.1.  Hairpinning by the SIIT-DC Border Relay . . . . . . . . .  11
+     5.2.  Additional EAMs Configured in Edge Relay  . . . . . . . .  12
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
+   Appendix A.  Examples: Network-Based IPv4 Connectivity  . . . . .  16
+     A.1.  Subnet with IPv4 Service Addresses  . . . . . . . . . . .  16
+     A.2.  Subnet with Unrouted IPv4 Addresses . . . . . . . . . . .  16
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17
+
+
+
+
+
+
+
+
+
+
+
+Anderson & Steffann           Informational                     [Page 2]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+1.  Introduction
+
+   SIIT-DC [RFC7755] describes an architecture where IPv4-only users can
+   access IPv6-only services through a stateless translator called an
+   SIIT-DC 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  Nodes that cannot connect to IPv6 networks at all or that can only
+      connect such networks if they also provide IPv4 connectivity
+      (i.e., dual-stacked networks).
+
+   o  Application software that 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 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 ER is to reverse the IPv4-to-IPv6 packet
+   translations previously done by the BR for traffic arriving from IPv4
+   clients and forward this as "native" IPv4 to the node or application.
+   In the reverse direction, IPv4 packets transmitted by the node or
+   application are intercepted by the ER, which translates them to IPv6
+   before they are forwarded to the BR, which in turn will reverse the
+   translations and forward them to the IPv4 client.  The node or
+   application 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 performs stateless protocol
+      translation between IPv4 and IPv6.  It MUST do so in accordance
+      with [RFC6145] and [RFC7757].
+
+
+
+
+
+
+
+
+
+
+Anderson & Steffann           Informational                     [Page 3]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+   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
+      outer network border of the Internet Data Center (IDC).  An ER may
+      be either node based (Section 3.1) or network based (Section 3.2).
+
+   IPv4 Service Address:
+      An IPv4 address representing a node or service located in an IPv6
+      network.  It is coupled with an IPv6 Service Address using an
+      Explicit Address Mapping (EAM).  Packets sent to this address are
+      translated to IPv6 by the BR, and possibly back to IPv4 by an ER,
+      before reaching the node or service.
+
+   IPv6 Service Address:
+      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 using an EAM.  IPv4-only clients
+      communicate with the IPv6 Service Address through SIIT-DC.
+
+   Explicit Address Mapping (EAM):
+      A bidirectional coupling between an IPv4 Service Address and an
+      IPv6 Service Address configured in a BR or ER.  When translating
+      between IPv4 and IPv6, the BR/ER changes the address fields in the
+      translated packet's IP header according to any matching EAM.  The
+      EAM algorithm is specified in [RFC7757].
+
+   Translation Prefix:
+      An IPv6 prefix into which the entire IPv4 address space is mapped,
+      according to the algorithm in [RFC6052].  The translation prefix
+      is routed to the BR's IPv6 interface.  When translating between
+      IPv4 and IPv6, a BR/ER will insert/remove the translation prefix
+      into/from the address fields in the translated packet's IP header,
+      unless 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 Center"; a data center whose main purpose
+      is to deliver services to the public Internet.  SIIT-DC is
+      primarily targeted at being deployed in an IDC.  An IDC is
+      typically operated by an Internet Content Provider or a Managed
+      Services Provider.
+
+
+
+
+
+
+Anderson & Steffann           Informational                     [Page 4]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+   SIIT:
+      The Stateless IP/ICMP Translation Algorithm, as specified in
+      [RFC6145].
+
+   XLAT:
+      Short for "Translation".  Used in figures to indicate where a BR/
+      ER uses SIIT [RFC6145] 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 Relay Description
+
+   An ER is at its core an implementation of the Stateless IP/ICMP
+   Translation Algorithm [RFC6145] that supports Explicit Address
+   Mappings [RFC7757].  It provides virtual IPv4 connectivity for nodes
+   or applications that require this to operate correctly with SIIT-DC.
+
+   Packets from the IPv4 Internet destined for an IPv4 Service Address
+   are first translated to IPv6 by a BR.  The resulting IPv6 packets are
+   subsequently forwarded to the ER that owns the IPv6 Service Address
+   the translated packets are addressed to.  The ER then translates them
+   back to IPv4 before forwarding them to the IPv4 application or node.
+   In the other direction, the exact same translations happen, only in
+   reverse.  This process provides end-to-end transparency of IPv4
+   addresses.
+
+   An ER may handle an arbitrary number of IPv4/IPv6 Service Addresses.
+   All the EAMs configured in the BR that involve the IPv4/IPv6 Service
+   Addresses handled by an ER MUST also be present in the ER's
+   configuration.
+
+   An ER may be implemented in two distinct ways: as a software-based
+   service residing inside an otherwise IPv6-only node or as a network-
+   based service that provides an isolated IPv4 network segment to 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 node or application supports it.
+
+   The choice between a node- or network-based ER is made on a per-
+   service or per-node basis.  An arbitrary number of each type of 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.
+
+
+
+Anderson & Steffann           Informational                     [Page 5]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+3.1.  Node-Based Edge Relay
+
+    [IPv4 Internet]  [IPv6 Internet]
+          |            |
+    +-----|-----+      |
+    | (BR/XLAT) |      |
+    +-----|-----+      |
+          |            |      +-----<IPv6-only node/server>----------+
+    [IPv6-only IDC network]   |                    +----------------+|
+       |                      |  /--(ER/XLAT)--AF_INET  Dual-stack  ||
+       \-------------------------+                 |    application ||
+                              |  \------------AF_INET6  software    ||
+                              |                    +----------------+|
+                              +--------------------------------------+
+
+                     Figure 1: A Node-Based Edge Relay
+
+   A node-based ER is typically implemented as a logical software
+   function that runs inside the operating system of an IPv6 node.  It
+   provides applications running on the same node with IPv4
+   connectivity.  Its IPv4 Service Address SHOULD be considered a
+   regular local address that allows applications running on the same
+   node to use it with IPv4-only API calls, e.g., to create AF_INET
+   sockets that listen for and accept incoming connections to its IPv4
+   Service Address.  An ER may accomplish this by creating 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 supports dual-stack
+   operation, IPv6 clients will be able to communicate with it directly
+   using native IPv6.  Neither the BR nor the ER will intercept this
+   communication.  Support for IPv6 in the application is, however, not
+   a requirement; the application 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 BR) will continue work in
+   the same way.
+
+   The ER requires a dedicated IPv6 Service Address for each IPv4
+   Service Address it has configured.  The IPv6 network MUST forward
+   traffic to these IPv6 Service Addresses to the node, whose operating
+   system MUST in turn forward them to the 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 way would be to assign the ER's IPv6
+
+
+
+Anderson & Steffann           Informational                     [Page 6]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+   Service Addresses as secondary IPv6 addresses on the node itself so
+   that the upstream router learns of their location using the IPv6
+   Neighbor Discovery Protocol [RFC4861].
+
+3.2.  Network-Based Edge Relay
+
+         [IPv4 Internet]  [IPv6 Internet]
+               |             |
+         +-----|-----+       |
+         | (BR/XLAT) |       |
+         +-----|-----+       |
+               |             |
+          [IPv6-only IDC network]   +--<IPv4-only node/server>--+
+               |                    |         +----------------+|
+         +-----|-----+   [v4-only]  |         |    IPv4-only   ||
+         | (ER/XLAT)-----[network]--------AF_INET  application ||
+         +-----------+   [segment]  |         |    software    ||
+                                    |         +----------------+|
+                                    +---------------------------+
+
+                Figure 2: A Basic Network-Based Edge Relay
+
+   A network-based ER functions the exact same way as a 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 nodes that require IPv4
+   connectivity connect to.  The ER also functions as the default IPv4
+   router for the nodes on this network segment.
+
+   Each node on the IPv4 network segment MUST acquire and assign an IPv4
+   Service Address to a local network interface.  While this document
+   does not attempt to explore all the various methods by which this
+   could be accomplished, some examples are provided in Appendix A.
+
+   The basic ER illustrated in Figure 2 establishes an IPv4-only network
+   segment between itself and the IPv4-only nodes it serves.  This is
+   fine if the nodes it provides IPv4 access to have no support for IPv6
+   whatsoever; however, if they are dual-stack capable, it would not be
+   ideal to take away their IPv6 connectivity in this manner.  While it
+   is RECOMMENDED to use a node-based ER in this case, appropriate
+   implementations of a node-based ER might not be available for every
+   node.  If the application protocol in question does not work
+   correctly in a NAT environment, standard SIIT-DC cannot be used
+   either, which leaves a network-based ER as the only remaining
+   solution.  The following subsections contain examples on how the ER
+   could be implemented in a way that provides IPv6 connectivity for
+   dual-stack capable nodes.
+
+
+
+
+Anderson & Steffann           Informational                     [Page 7]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+3.2.1.  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: A Network-Based Edge Relay "on a Stick"
+
+   The ER "on a stick" approach illustrated in Figure 3 ensures that the
+   dual-stack capable node retains native IPv6 connectivity by
+   connecting the ER's IPv4 and IPv6 interfaces to the same network
+   segment, alternatively by using a single dual-stacked interface.
+   Native IPv6 traffic between the IDC network and the node bypasses the
+   ER entirely, while IPv4 traffic from the node will be routed directly
+   to the ER (because it acts as its default IPv4 router), where it is
+   translated to IPv6 before being transmitted to the upstream default
+   IPv6 router.  The ER could attract inbound traffic to the IPv6
+   Service Addresses by responding to the upstream router's IPv6
+   Neighbor Discovery [RFC4861] messages for them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Anderson & Steffann           Informational                     [Page 8]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+3.2.2.  Edge Relay That Bridges IPv6 Packets
+
+       [IPv4 Internet]  [IPv6 Internet]
+             |             |
+       +-----|-----+       |
+       | (BR/XLAT) |       |
+       +-----|-----+       |
+             |             |
+        [IPv6-only IDC network]
+                   |
+       +-----------|--------------+
+       |      ____/ \_IPv6_       |
+       |     /             \      |
+       | (IPv6 Bridge)  (ER/XLAT) |
+       |     \____   _    _/      |
+       |          \ / IPv4        |   +--<Dual-stack node/server>--+
+       +-----------|--------------+   |          +----------------+|
+                   |                  |  /---AF_INET  Dual-stack  ||
+        [Dual-stack network segment]----<        |    application ||
+                                      |  \--AF_INET6  software    ||
+                                      |          +----------------+|
+                                      +----------------------------+
+
+      Figure 4: A Network-Based Edge Relay Containing an IPv6 Bridge
+
+   The ER illustrated in Figure 4 will transparently bridge IPv6 frames
+   between its upstream and downstream interfaces.  IPv6 packets sent
+   from the upstream IDC network to an IPv6 Service Address are
+   intercepted by the ER (e.g., by responding to IPv6 Neighbor Discovery
+   [RFC4861] messages for them) and routed through the translation
+   function before being forwarded out the ER's downstream interface as
+   IPv4 packets.  The downstream network segment thus becomes dual
+   stacked.
+
+4.  Deployment Considerations
+
+4.1.  IPv6 Path MTU
+
+   The IPv6 Path MTU between the ER and the BR will typically be larger
+   than the default value defined in Section 4 of [RFC6145] (1280
+   bytes), as it will typically be contained within a single
+   administrative domain.  Therefore, it is RECOMMENDED that the IPv6
+   Path MTU configured in the ER be raised accordingly.  It is
+   RECOMMENDED that the ER and the BR use identical configured IPv6 Path
+   MTU values.
+
+
+
+
+
+
+Anderson & Steffann           Informational                     [Page 9]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+4.2.  IPv4 MTU
+
+   In order to avoid IPv6 fragmentation, an ER SHOULD ensure that the
+   IPv4 MTU used by applications or nodes is equal to the configured
+   IPv6 Path MTU - 20 so that a maximum-sized IPv4 packet can fit in an
+   unfragmented IPv6 packet.  This ensures that the application may do
+   its part in avoiding IP-level fragmentation from occurring, e.g., by
+   segmenting/fragmenting outbound packets at the application layer, and
+   advertising the maximum size its peer may use for inbound packets
+   (e.g., through the use of the TCP Maximum Segment Size (MSS) option).
+
+   A node-based ER could accomplish this by configuring this MTU value
+   on the virtual network adapter, while a network-based ER could do so
+   by advertising the MTU to its downstream nodes using the DHCPv4
+   Interface MTU option [RFC2132].
+
+4.3.  IPv4 Identification Header
+
+   If the generation of IPv6 Atomic Fragments is disabled, the value of
+   the IPv4 Identification header will be lost during the translation.
+   Conversely, enabling the generation of IPv6 Atomic Fragments will
+   ensure that the IPv4 Identification header will be carried end to
+   end.  Note that for this to work bidirectionally, IPv6 Atomic
+   Fragment generation MUST be enabled on both the BR and the ER.
+
+   Apart from certain diagnostic tools, there are few (if any)
+   application protocols that make use of the IPv4 Identification
+   header.  Therefore, the loss of the IPv4 Identification value will
+   generally not cause any problems.
+
+   IPv6 Atomic Fragments and their impact on the IPv4 Identification
+   header is further discussed in Section 4.9.2 of [RFC7755].
+
+5.  Intra-IDC IPv4 Communication
+
+   Although SIIT-DC is primarily intended to facilitate communication
+   between IPv4-only nodes on the 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 IDC.  The IPv4-only node or application will need to go
+   through the ER, as it will typically be incapable of contacting IPv6
+   destinations directly.  The following subsections discuss various
+   methods on how to facilitate such communication.
+
+
+
+
+
+
+
+
+Anderson & Steffann           Informational                    [Page 10]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+5.1.  Hairpinning by the SIIT-DC Border Relay
+
+   If the BR supports hairpinning as described in Section 4.2 of
+   [RFC7757], the easiest solution is to make the target service
+   available through SIIT-DC in the normal way; that is, by provisioning
+   an EAM to the BR that assigns an IPv4 Service Address with the target
+   service's IPv6 Service Address.
+
+   This allows the IPv4-only node or application to transmit packets
+   destined for the target service's IPv4 Service Address, which the ER
+   will then translate to a corresponding IPv4-converted IPv6 address by
+   inserting the translation prefix [RFC6052].  When this IPv6 packet
+   reaches the BR, it will be hairpinned and transmitted back to the
+   target service's IPv6 Service Address (where it could possibly pass
+   through another ER before reaching the target service).  Return
+   traffic from the target service will be hairpinned in the same
+   fashion.
+
+   +-[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: Hairpinned IPv4-IPv4 Packet Flow
+
+   Figure 5 illustrates the flow of a hairpinned packet sent from the
+   IPv4-only node/app behind ER A towards an IPv6-only node/app behind
+   ER B.  ER A is configured with the EAM {192.0.2.1,2001:db8:a::} and
+   ER B with {192.0.2.2,2001:db8:b::}.  The BR is configured with both
+   EAMs and supports hairpinning.  Note that if the target service had
+   not been located behind an ER, the third and final translation
+   (XLAT#3) would not have happened, i.e., the target service/node would
+   have received and responded to packet #3 directly.
+
+   If the IPv4-only nodes/services do not need connectivity with the
+   public IPv4 Internet, private IPv4 addresses [RFC1918] could be used
+   as their IPv4 Service Addresses in order to conserve the IDC
+   operator's pool of public IPv4 addresses.
+
+
+
+
+
+
+
+
+Anderson & Steffann           Informational                    [Page 11]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+5.2.  Additional EAMs Configured in Edge Relay
+
+   If the BR does not support hairpinning, or if the hairpinning
+   solution is not desired for some other reason, intra-IDC IPv4 traffic
+   may be facilitated by configuring additional EAMs on the ER for each
+   service the IPv4-only node or application needs to communicate with.
+   This makes the IPv6 traffic between the ER and the target service's
+   IPv6 Service Address follow the direct path through the IPv6 network.
+   The traffic does not pass the BR, which means that this solution
+   might yield better latency than the hairpinning approach.
+
+   The additional EAM configured in the ER consists of the target's IPv6
+   Service Address and an IPv4 Service Address.  The IPv4-only node or
+   application will contact the target's assigned IPv4 Service Address
+   using its own IPv4 Service Address as the source.  The ER will then
+   proceed to translate the original IPv4 packet to an IPv6 packet.  The
+   source address of the resulting IPv6 packet will be the IPv6 Service
+   Address of the local node or application, while the destination
+   address will be the IPv6 Service Address of the target.  Any replies
+   from the target will undergo identical translation, only in reverse.
+
+   If the target service is located behind another ER, that other ER
+   MUST also be provisioned with an additional EAM that contains the
+   IPv4 and IPv6 Service Addresses of the origin IPv4-only node or
+   application.  Otherwise, the target service's ER will be unable to
+   translate the source address of the incoming packets.
+
+            +-[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:b:: |
+            +---------------+             +------------------+
+                                                   |
+            +-[Pkt#3: IPv4]-+                      |
+            | SRC 192.0.2.1 |        (XLAT#2)      |
+            | DST 192.0.2.2 |<-------(@ ER B)------/
+            +---------------+
+
+              Figure 6: Non-hairpinned IPv4-IPv4 Packet Flow
+
+   Figure 6 illustrates the flow of a packet carrying intra-IDC IPv4
+   traffic between two IPv4-only 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 regular routing path through the IPv6 IDC network;
+   the BR is not involved, and the packet will not be hairpinned.
+
+
+
+
+
+
+Anderson & Steffann           Informational                    [Page 12]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+   The above approach is not mutually exclusive with the hairpinning
+   approach described in Section 5.1: If both EAMs above are also
+   configured on the BR, both 192.0.2.1 and 192.0.2.2 would be reachable
+   from other IPv4-only services/nodes using the hairpinning approach.
+   They would also be reachable from the IPv4 Internet.
+
+   Note that if the target service in this example was not located
+   behind an ER, but instead was a native IPv6 service listening on
+   2001:db8:b::, the second translation step in Figure 6 would not
+   occur; the target service would receive and respond to packet #2
+   directly.
+
+   As with the hairpinning approach, if the IPv4-only nodes/services do
+   not need connectivity to/from the public IPv4 Internet, private IPv4
+   addresses [RFC1918] could be used as their IPv4 Service Addresses.
+   Alternatively, in the case where the target service is on native
+   IPv6, the target's assigned IPv4 Service Address has only local
+   significance behind the ER.  It could therefore be assigned from the
+   IPv4 Service Continuity Prefix [RFC7335].
+
+6.  Security Considerations
+
+   This section discusses security considerations specific to the use of
+   an ER.  See the Security Considerations section in [RFC7755] for
+   security considerations applicable to the SIIT-DC architecture in
+   general.
+
+   If the ER receives an IPv4 packet from the application/node from a
+   source address it does not have an EAM for, both the source and
+   destination addresses will be rewritten according to [RFC6052].
+   After undergoing the reverse translation in the BR, the resulting
+   IPv4 packet routed to the IPv4 network will have a spoofed IPv4
+   source address.  The 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 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.
+
+
+
+
+
+Anderson & Steffann           Informational                    [Page 13]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC7755]  Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
+              IPv6 Data Center Environments", RFC 7755,
+              DOI 10.17487/RFC7755, February 2016,
+              <http://www.rfc-editor.org/info/rfc7755>.
+
+   [RFC7757]  Anderson, T. and A. Leiva, "Explicit Address Mappings for
+              Stateless IP/ICMP Translation", RFC 7757,
+              DOI 10.17487/RFC7757, February 2016,
+              <http://www.rfc-editor.org/info/rfc7757>.
+
+7.2.  Informative References
+
+   [RFC826]   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, DOI 10.17487/RFC0826, November 1982,
+              <http://www.rfc-editor.org/info/rfc826>.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+              and E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
+              <http://www.rfc-editor.org/info/rfc1918>.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
+              RFC 2131, DOI 10.17487/RFC2131, March 1997,
+              <http://www.rfc-editor.org/info/rfc2131>.
+
+   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+              Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
+              <http://www.rfc-editor.org/info/rfc2132>.
+
+   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
+              Defeating Denial of Service Attacks which employ IP Source
+              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
+              May 2000, <http://www.rfc-editor.org/info/rfc2827>.
+
+
+
+
+
+
+
+Anderson & Steffann           Informational                    [Page 14]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              DOI 10.17487/RFC4861, September 2007,
+              <http://www.rfc-editor.org/info/rfc4861>.
+
+   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+              DOI 10.17487/RFC6052, October 2010,
+              <http://www.rfc-editor.org/info/rfc6052>.
+
+   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
+              Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
+              <http://www.rfc-editor.org/info/rfc6145>.
+
+   [RFC6535]  Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
+              Using "Bump-in-the-Host" (BIH)", RFC 6535,
+              DOI 10.17487/RFC6535, February 2012,
+              <http://www.rfc-editor.org/info/rfc6535>.
+
+   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
+              "Default Address Selection for Internet Protocol Version 6
+              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
+              <http://www.rfc-editor.org/info/rfc6724>.
+
+   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
+              Combination of Stateful and Stateless Translation",
+              RFC 6877, DOI 10.17487/RFC6877, April 2013,
+              <http://www.rfc-editor.org/info/rfc6877>.
+
+   [RFC7335]  Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335,
+              DOI 10.17487/RFC7335, August 2014,
+              <http://www.rfc-editor.org/info/rfc7335>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Anderson & Steffann           Informational                    [Page 15]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+Appendix A.  Examples: Network-Based IPv4 Connectivity
+
+A.1.  Subnet with IPv4 Service Addresses
+
+   One relatively straight-forward way to provide IPv4 connectivity
+   between a network-based ER and the IPv4 node(s) it serves is to
+   ensure the IPv4 Service Address(es) can be enclosed within a larger
+   IPv4 prefix.  The ER may then claim one address in this prefix for
+   itself and use it to provide an IPv4 default router address and
+   assign the IPv4 Service Address(es) to its downstream node(s) using
+   DHCPv4 [RFC2131].  For example, if the IPv4 Service Addresses are
+   192.0.2.26 and 192.0.2.27, the ER 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 between
+   the IPv4 node(s) behind the 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 IPv4 nodes
+   will mistakenly believe they have an on-link route to the entire
+   prefix and attempt to resolve the addresses using ARP [RFC826],
+   instead of sending them to the ER for translation to IPv6.  This
+   problem could, however, be overcome by avoiding assigning IPv4
+   Service Addresses that overlap with an IPv4 prefix handled by an ER
+   (at the expense of wasting some potential IPv4 Service Addresses) or
+   by ensuring that the overlapping IPv4 Service Addresses are only
+   assigned to services that do not need to communicate with the 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 problem discussed in Appendix A.1, a private
+   unrouted IPv4 network that does not encompass the IPv4 Service
+   Address(es) could be used to provide connectivity between the ER and
+   the IPv4-only node(s) it serves.  An IPv4-only node must then assign
+   its IPv4 Service Address as a secondary local address, while the ER
+   routes each of the IPv4 Service Addresses to its assigned node using
+   that node's private on-link IPv4 address as the next hop.  This
+   approach would ensure there are no overlaps with IPv4 Service
+   Addresses elsewhere in the infrastructure, but on the other hand, it
+   would preclude the use of DHCPv4 [RFC2131] for assigning the IPv4
+   Service Addresses.
+
+
+
+
+
+
+
+Anderson & Steffann           Informational                    [Page 16]
+
+RFC 7756             SIIT-DC: Dual Translation Mode        February 2016
+
+
+   This approach creates a need to ensure that the IPv4 application is
+   selecting the IPv4 Service Address (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.
+
+Acknowledgements
+
+   The authors would like to especially thank the authors of 464XLAT
+   [RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne.
+   The architecture described by this document is merely an adaptation
+   of their work to a data center environment and could not have
+   happened without them.
+
+   The authors would like also to thank the following individuals for
+   their contributions, suggestions, corrections, and criticisms: Fred
+   Baker, Tobias Brox, Olafur Gudmundsson, Christer Holmberg, Ray
+   Hunter, Shucheng LIU (Will), and Andrew Yourtchenko.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+Anderson & Steffann           Informational                    [Page 17]
+