GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7756

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7756.txt · Last modified: 2016/02/18 03:22 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki