diff options
Diffstat (limited to 'doc/rfc/rfc7756.txt')
| -rw-r--r-- | doc/rfc/rfc7756.txt | 955 |
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] + |