draft-ietf-v6ops-siit-dc-2xlat-00.txt   draft-ietf-v6ops-siit-dc-2xlat-01.txt 
IPv6 Operations T. Anderson IPv6 Operations T. Anderson
Internet-Draft Redpill Linpro Internet-Draft Redpill Linpro
Intended status: Standards Track January 25, 2015 Intended status: Informational S. Steffann
Expires: July 29, 2015 Expires: December 30, 2015 S.J.M. Steffann Consultancy
June 28, 2015
SIIT-DC: Dual Translation Mode SIIT-DC: Dual Translation Mode
draft-ietf-v6ops-siit-dc-2xlat-00 draft-ietf-v6ops-siit-dc-2xlat-01
Abstract Abstract
This document describes an extension of the Stateless IP/ICMP This document describes an extension of the Stateless IP/ICMP
Translation for IPv6 Data Centre Environments architecture (SIIT-DC), Translation for IPv6 Internet Data Centre Environments architecture
which allows applications, protocols, or nodes that are incompatible (SIIT-DC), which allows applications, protocols, or nodes that are
with IPv6, SIIT-DC and/or Network Address Translation in general to incompatible with IPv6, and/or Network Address Translation to operate
operate correctly in an SIIT-DC environment. This is accomplished by correctly in an SIIT-DC environment. This is accomplished by
introducing a new component called an Edge Translator, which reverses introducing a new component called an SIIT-DC Edge Relay, which
the translations made by an SIIT-DC Gateway. The application or reverses the translations made by an SIIT-DC Border Relay. The
device is thus provided with seemingly native IPv4 connectivity. 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 The reader is expected to be familiar with the SIIT-DC architecture
described in I-D.ietf-v6ops-siit-dc. described in I-D.ietf-v6ops-siit-dc.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 29, 2015. This Internet-Draft will expire on December 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Edge Translator Description . . . . . . . . . . . . . . . . . 4 3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 4
3.1. Host-Based Edge Translator . . . . . . . . . . . . . . . 5 3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 5
3.2. Network-Based Edge Translator . . . . . . . . . . . . . . 6 3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 6
4. Detailed Topology Example . . . . . . . . . . . . . . . . . . 9 3.2.1. Edge Router "On A Stick" . . . . . . . . . . . . . . 7
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 3.2.2. Edge Router that Bridges IPv6 Packets . . . . . . . . 8
5.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 12 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
5.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 9
5.3. IPv4 Identification Header . . . . . . . . . . . . . . . 12 4.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Intra-DC IPv4 Communication . . . . . . . . . . . . . . . . . 13 4.3. IPv4 Identification Header . . . . . . . . . . . . . . . 10
6.1. Between IPv4-Only and IPv6-Only Services . . . . . . . . 13 5. Intra-IDC IPv4 Communication . . . . . . . . . . . . . . . . 10
6.2. Between Two IPv4-Only Services . . . . . . . . . . . . . 15 5.1. Hairpinning by the SIIT-DC Border Relay . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Address Spoofing . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Address Spoofing . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 15
A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 15
A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
SIIT-DC [I-D.ietf-v6ops-siit-dc] describes an architecture where SIIT-DC [I-D.ietf-v6ops-siit-dc] describes an architecture where
IPv4-only users can access IPv6-only services through a stateless IPv4-only users can access IPv6-only services through a stateless
translator called an SIIT-DC Gateway. This approach has certain translator called an SIIT-DC Border Relay (BR). This approach has
limitations, however. In particular, the following cases will work certain limitations, however. In particular, the following cases
poorly or not at all: will work poorly or not at all:
o Application protocols that do not support NAT (i.e., the lack of o Application protocols that do not support NAT (i.e., the lack of
end-to-end transparency of IP addresses). end-to-end transparency of IP addresses).
o Devices which cannot connect to IPv6 networks at all, or which can o Nodes that cannot connect to IPv6 networks at all, or that can
only connect such networks if they also provide IPv4 connectivity only connect such networks if they also provide IPv4 connectivity
(i.e., dual-stacked networks). (i.e., dual-stacked networks).
o Application software which makes use of legacy IPv4-only APIs, or o Application software which makes use of legacy IPv4-only APIs, or
otherwise makes assumptions that IPv4 connectivity is available. otherwise makes assumptions that IPv4 connectivity is available.
By extending the SIIT-DC architecture with a new component called an By extending the SIIT-DC architecture with a new component called an
Edge Translator (ET), all of the above can be made to work correctly Edge Relay (ER), all of the above can be made to work correctly in an
in an otherwise IPv6-only network environment using SIIT-DC. otherwise IPv6-only network environment using SIIT-DC.
The purpose of the Edge Translator is to reverse the IPv4-to-IPv6 The purpose of the ER is to reverse the IPv4-to-IPv6 packet
packet translations previously done by the SIIT-DC Gateway for translations previously done by the BR for traffic arriving from IPv4
traffic arriving from IPv4 clients and forward this as "native" IPv4 clients and forward this as "native" IPv4 to the node or application.
to the application software or device. In the reverse direction, In the reverse direction, IPv4 packets transmitted by the node or
IPv4 packets transmitted by the application software or device is application are intercepted by the ER, which translates them to IPv6
intercepted by the Edge Translator, which will translate them to IPv6 before they are forwarded to the BR, which in turn will reverse the
before they are forwarded to the SIIT-DC Gateway, which in turn will translations and forward them to the IPv4 client. The node or
reverse the translations and forward them to the IPv4 End User. In application is thus provided with "virtual" IPv4 Internet
short, the device or application software is provided with "virtual" connectivity that retains end-to-end transparency for the IPv4
IPv4 Internet connectivity that retains end-to-end transparency for addresses.
the IPv4 addresses.
2. Terminology 2. Terminology
This document makes use of the following terms: This document makes use of the following terms:
Edge Translator (ET) SIIT-DC Border Relay (BR)
A device or a logical function that translates traffic between
IPv4 clients and IPv6 services. See [I-D.ietf-v6ops-siit-dc].
SIIT-DC Edge Relay (ER)
A device or logical function that provides "native" IPv4 A device or logical function that provides "native" IPv4
connectivity to IPv4-only devices or application software. It is connectivity to IPv4-only nodes or applications. It functions in
very similar in function to an SIIT-DC Gateway, but is typically the same way as a BR, but is located close to the IPv4-only nodes/
located close to the IPv4-only component(s) it is supporting applications it is supporting rather than on the network border.
rather than on the network border.
IPv4 Service Address IPv4 Service Address
A public IPv4 address with which IPv4-only clients will An IPv4 address representing an IPv6 service, with which IPv4-only
communicate. This communication will be translated to IPv6 by the clients communicates. It is coupled with an IPv6 Service Address
SIIT-DC Gateway and back to IPv4 again by the Edge Translator. using an EAM. Packets sent to this address is translated to IPv6
by the BR and possibly back to IPv4 again by the ER, and vice
versa in the opposite direction.
SIIT-DC Gateway IPv6 Service Address
A device or a logical function that translates between IPv4 and An IPv6 address assigned to an application, node, or service;
IPv6 in accordance with [I-D.ietf-v6ops-siit-dc]. either directly or indirectly (through an ER). It is coupled with
an IPv4 Service Address using an EAM. IPv4-only clients
communicates with the IPv6 Service Address through SIIT-DC.
Static Address Mapping Explicit Address Mapping (EAM)
A bi-directional mapping between an IPv4 Service Address and an A bi-directional coupling between an IPv4 Service Address and an
IPv6 Service Address configured in the SIIT-DC Gateway. When IPv6 Service Address configured in an BR/ER. When translating
translating between IPv4 and IPv6, the SIIT-DC Gateway changes the between IPv4 and IPv6, the BR/ER changes the address fields in the
address fields in the translated packet's IP header according to translated packet's IP header according to any matching EAM. The
any matching Static Address Mapping. EAM algorithm is specified in [I-D.ietf-v6ops-siit-eam].
Translation Prefix Translation Prefix
An IPv6 prefix into which the entire IPv4 address space is mapped. An IPv6 prefix into which the entire IPv4 address space is mapped,
This prefix is routed to the SIIT-DC Gateway's IPv6 interface. It according to the algorithm in [RFC6052]. The Translation Prefix
is either an Network-Specific Prefix or a Well-Known Prefix as is routed to the BR's IPv6 interface. When translating between
specified in [RFC6052]. When translating between IPv4 and IPv6, IPv4 and IPv6, an BR/ER will insert/remove the Translation Prefix
the SIIT-DC Gateway will prepend or strip the Translation Prefix into/from the address fields in the translated packet's IP header,
from the address fields in the translated packet's IP header, unless an EAM exists for the IP address that is being translated.
unless a Static Address Mapping exists for the IP address in
question. IPv4-converted IPv6 addresses
As defined in Section 1.3 of [RFC6052].
IDC
Short for "Internet Data Centre"; a data centre whose main purpose
is to deliver services to the public Internet, the use case SIIT-
DC is primarily targeted at. IDCs are typically operated by
Internet Content Providers or Managed Services Providers.
SIIT
The Stateless IP/ICMP Translation algorithm, as specified in
[RFC6145].
XLAT XLAT
Used in figures to indicate where the Stateless IP/ICMP Short for "Translation". Used in figures to indicate where a BR/
Translation [RFC6145] algorithm is used to translate IPv4 packets ER uses SIIT [RFC6145] to translate IPv4 packets to IPv6 and vice
to IPv6 and vice versa. versa.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Edge Translator Description 3. Edge Relay Description
An Edge Translator (ET) is at its core an implementation of the An Edge Relay (ER) is at its core an implementation of the Stateless
Stateless IP/ICMP Translation algorithm [RFC6145], with the Static IP/ICMP Translation algorithm [RFC6145] that supports Explicit
Address Mapping extension described in Section 5.2 of Address Mappings [I-D.ietf-v6ops-siit-eam]. It provides virtual IPv4
[I-D.ietf-v6ops-siit-dc]. It provides virtual IPv4 connectivity for connectivity for nodes or applications which require this to operate
application software or devices which require this to operate
correctly in an SIIT-DC environment. correctly in an SIIT-DC environment.
Inbound IPv4 packets destined for an IPv4 Service Address is first Packets from the IPv4 Internet destined for an IPv4 Service Address
translated to IPv6 by an SIIT-DC Gateway. The resulting IPv6 packets is first translated to IPv6 by a BR. The resulting IPv6 packets are
are subsequently forwarded to the ET handling the IPv6 Service subsequently forwarded to the ER that owns the IPv6 Service Address
Address they are addressed to. The ET then translates them back to the translated packets are addressed to. The ER then translates them
IPv4 before forwarding them to the IPv4 application software or back to IPv4 before forwarding them to the IPv4 application or node.
device. In the other direction, the exact same translations happen, In the other direction, the exact same translations happen, only in
only in reverse. This process provides end-to-end transparency of reverse. This process provides end-to-end transparency of IPv4
IPv4 addresses. addresses.
An ET may handle an arbitrary number of IPv4 Service Addresses. All An ER may handle an arbitrary number of IPv4/IPv6 Service Addresses.
the Static Address Mappings configured in the SIIT-DC Gateway(s) that All the EAMs configured in the BR that involve the IPv4/IPv6 Service
involve the IPv4 Service Addresses handled by an ET MUST be Addresses handled by an ER MUST also be present in the ER's
duplicated in that ET's configuration. configuration.
An ET may be implemented in two distinct ways; as a software-based An ER may be implemented in two distinct ways; as a software-based
service residing inside an otherwise IPv6-only host, or as a network- service residing inside an otherwise IPv6-only node, or as a network-
based service that provides an isolated IPv4 network segment to which based service that provides an isolated IPv4 network segment to which
devices which require IPv4 can connect. In both cases native IPv6 nodes that require IPv4 can connect. In both cases native IPv6
connectivity may be provided simultaneously with the virtual IPv4 connectivity may be provided simultaneously with the virtual IPv4
connectivity. Thus, dual-stack connectivity is facilitated in case connectivity. Thus, dual-stack connectivity is facilitated in case
the device or application software support it. the node or application support it.
The choice between a host- or network-based ET is made on a per- The choice between a node- or network-based ER is made on a per-
service or -device basis. An arbitrary number of each type of ET may service or per-node basis. An arbitrary number of each type of ER
co-exist in an SIIT-DC architecture. may co-exist in an SIIT-DC architecture.
This section describes the different approaches and discusses which This section describes the different approaches and discusses which
approach fits best for the various use cases. approach fits best for the various use cases.
3.1. Host-Based Edge Translator 3.1. Node-Based Edge Relay
Overview of a Host-based Edge Translator A Node-based Edge Relay
[IPv4 Internet] [IPv6 Internet] [IPv4 Internet] [IPv6 Internet]
| | | |
+--|--<SIIT-DC GW>--+ | +-----|-----+ |
| [XLAT] | | | (BR/XLAT) | |
+--|----------------+ | +-----|-----+ |
| | | | +-----<IPv6-only node/server>----------+
[IPv6-only data centre network] [IPv6-only IDC network] | +----------------+|
| | | /--(ER/XLAT)--AF_INET Dual-stack ||
+--|--<IPv6-only server>---------------+ \-------------------------+ | Application ||
| | +----------------+| | \------------AF_INET6 Software ||
| +--[ET/XLAT]--AF_INET Dual-stack || | +----------------+|
| | | Application || +--------------------------------------+
| \------------AF_INET6 Software ||
| +----------------+|
+--------------------------------------+
Figure 1 Figure 1
A host-based Edge Translator is typically implemented as a logical A node-based ER is typically implemented as a logical software
software function that runs inside the operating system of a host or function that runs inside the operating system of an IPv6 node. It
server. It provides software applications running on the same host provides applications running on the same node with IPv4
with IPv4 connectivity. The IPv4 Service Address it handles is connectivity. Its IPv4 Service Address SHOULD be considered a
considered local, allowing application software running on the same regular local address that allows application running on the same
host to use traditional IPv4-only API calls, e.g., to create AF_INET node to use it with IPv4-only API calls, e.g., to create AF_INET
sockets that listens for and accepts incoming connections to its IPv4 sockets that listen for and accept incoming connections to its IPv4
Service Address. An ET could accomplish this by creating an virtual Service Address. An ER may accomplish this by creating a virtual
network adapter to which it assigns the IPv4 Service Address and network adapter to which it assigns the IPv4 Service Address and
points a default IPv4 route. points a default IPv4 route. This approach is similar to the "Bump-
in-the-Stack" approach discussed in [RFC6535], however it does not
include an Extension Name Resolver.
As shown in Figure 1, if the application software supports dual-stack As shown in Figure 1, if the application supports dual-stack
operation, IPv6 clients will be able to communicate with it directly operation, IPv6 clients will be able to communicate with it directly
using native IPv6. Neither the SIIT-DC Gateway nor the ET will using native IPv6. Neither the BR nor the ER will intercept this
intercept this communication. Support for IPv6 in the application communication. Support for IPv6 in the application is however not a
software is however not a requirement; the application software may requirement; the application may opt not to establish any IPv6
opt not to establish any IPv6 sockets. Foregoing IPv6 in this manner sockets. Foregoing IPv6 in this manner will simply preclude
will simply preclude connectivity to the service from IPv6-only connectivity to the service from IPv6-only clients; connectivity to
clients; connectivity to the service from IPv4 clients (through the the service from IPv4 clients (through the BR) will continue work in
SIIT-DC Gateway) will work in the exact same manner in both cases. the same way.
The ET requires a dedicated IPv6 Service Address for each IPv4 The ER requires a dedicated IPv6 Service Address for each IPv4
Service Address it has configured. The IPv6 network must forward Service Address it has configured. The IPv6 network MUST forward
traffic to these IPv6 Service Addresses to the host, whose operating traffic to these IPv6 Service Addresses to the node, whose operating
system must in turn forward them to the ET. This document does not system MUST in turn forward them to the ER. This document does not
explore the multitude of ways this could be accomplished, however attempt to fully explore the multitude of ways this could be
considering that the IPv6 protocol is designed for having multiple accomplished, however considering that the IPv6 protocol is designed
addresses assigned to a single node, one particularly straight- for having multiple addresses assigned to a single node, one
forward way would be to assign the ET's IPv6 Service Addresses as particularly straight-forward way would be to assign the ER's IPv6
secondary IPv6 addresses on the host itself so that it the upstream Service Addresses as secondary IPv6 addresses on the node itself so
router learns of their location using the IPv6 Neighbor Discovery that it the upstream router learns of their location using the IPv6
Protocol [RFC4861]. Neighbor Discovery Protocol [RFC4861].
3.2. Network-Based Edge Translator 3.2. Network-Based Edge Relay
Overview of a Basic Network-based Edge Translator A Basic Network-based Edge Relay
[IPv4 Internet] [IPv6 Internet] [IPv4 Internet] [IPv6 Internet]
| | | |
+--|--<SIIT-DC GW>--+ | +-----|-----+ |
| [XLAT] | | | (BR/XLAT) | |
+--|----------------+ | +-----|-----+ |
| | | |
[IPv6-only data centre network] [IPv6-only IDC network] +--<IPv4-only node/server>--+
| | | +----------------+|
+--|--<ET>--+ +-----|-----+ [v4-only] | | IPv4-only ||
| [XLAT] | | (ER/XLAT)-----[network]--------AF_INET Application ||
+--|--------+ +-----------+ [segment] | | Software ||
| | +----------------+|
[Isolated IPv4-only network segment] +---------------------------+
|
+--|--<IPv4-only server>----+
| | +----------------+|
| \--AF_INET IPv4-only ||
| | Application ||
| | Software ||
| +----------------+|
+---------------------------+
Figure 2 Figure 2
A network-based Edge Translator performs the exact same as a host- A network-based ER performs the exact same as a node-based ER does,
based ET does, only that instead of assigning the IPv4 Service only that instead of assigning the IPv4 Service Addresses to an
Addresses to an internal-only virtual network adapter, traffic internal-only virtual network adapter, traffic destined for them are
destined for them are forwarded onto a network segment to which hosts forwarded onto a network segment to which nodes that require IPv4
that require IPv4 connectivity connect to. The ET also functions as connectivity connect to. The ER also functions as the default IPv4
the default IPv4 router for the hosts on this network segment. router for the nodes on this network segment.
Each host on the IPv4 network segment must acquire and assign an IPv4
Service Address to a local network interface. This document does not
attempt to explore all the various methods by which this can be
accomplished, however one relatively straight-forward possibility
would be to ensure the IPv4 Service Address(es) can be enclosed in an
IPv4 prefix. The ET will then claim one address in this prefix for
itself (used as the IPv4 default router address), and could assign
the IPv4 Service Address(es) to the host(s) using DHCPv4. For
example, if the IPv4 Service Addresses are 192.0.2.26 and 192.0.2.27,
the ET would configure the address 192.0.2.25/29 on its IPv4-facing
interface and would add the two IPv4 Service Addresses to its DHCPv4
pool.
One disadvantage of this method is that IPv4 communication between
the IPv4 hosts and other services made available through SIIT-DC
using the method described in Section 6 becomes impossible, if those
other services are assigned IPv4 Service Addresses that also are
covered by the same IPv4 prefix (e.g., 192.0.2.28). This is 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
(instead of forwarding them to the ET for translation to IPv6). This
problem could however be overcome by avoiding assigning IPv4 Service
Addresses which overlaps with an IPv4 prefix handled by an ET (at the
expense of wasting some potential IPv4 Service Addresses), or by
ensuring that they are only assigned to services which do not need to
communicate with the IPv4 host(s) behind the ET.
Another way to avoid the problem is to use a private unrouted IPv4 Each node on the IPv4 network segment MUST acquire and assign an IPv4
network that does not encompass the IPv4 Service Addresses as the Service Address to a local network interface. While this document
IPv4, and instead assign the IPv4 Service Addresses as secondary does not attempt to explore all the various methods by which this
addresses on the servers. The ET must then route each IPv4 Service could be accomplished, some examples are provided in Appendix A.
Address to its respective server using the server's private on-link
IPv4 address as the next-hop. This approach would ensure there are
no overlaps, but on the other hand it would preclude the use of
DHCPv4 for assigning the IPv4 Service Addresses, as well as create a
need to ensure that the IPv4 application software is selecting the
IPv4 Service Address (as opposed to its private on-link IPv4 address)
as its source address when initiating outbound connections.
The basic ET illustrated in Figure 2 establishes an IPv4-only network The basic ER illustrated in Figure 2 establishes an IPv4-only network
segment behind itself. This is fine if the devices it provides IPv4 segment between itself and the IPv4-only nodes it serves. This is
access have no support for IPv6 whatsoever; however if they are dual- fine if the nodes it provides IPv4 access have no support for IPv6
stack capable, it is would not be ideal to take away their IPv6 whatsoever; however if they are dual-stack capable, it is would not
connectivity. While it is recommended to use a host-based ET in this be ideal to take away their IPv6 connectivity in this manner. While
case, appropriate implementations of a host-based ET might not be it is RECOMMENDED to use a node-based ER in this case, appropriate
available for every device. If the application protocol does not implementations of a node-based ER might not be available for every
work correctly in a NAT environment, standard SIIT-DC cannot be used node. If the application protocol in question does not work
either. Thus, a network-based ET is the only solution. correctly in a NAT environment, standard SIIT-DC cannot be used
either, which leaves a network-based ER is the only remaining
solution. The following subsections contains examples on how the ER
could be implemented in a way that provides IPv6 connectivity for
dual-stack capable nodes.
The operator could avoid breaking the hosts' IPv4 connectivity by 3.2.1. Edge Router "On A Stick"
connecting the ET's IPv4 and IPv6 interfaces to the same network
segment, or by using a single dual-stacked interface instead. The
latter alternative is shown in Figure 3. This could be thought of as
an "ET on a stick". IPv6 traffic between the network and the hosts
will bypass the ET entirely. IPv4 traffic from the hosts will be
routed directly to the ET (because it's their default IPv4 router),
and translated to IPv6 before its being transmitted to the upstream
default IPv6 router. The ET could attract inbound traffic to its
IPv6 Service Addresses by responding to the upstream router's IPv6
Neighbor Discovery [RFC4861] messages for them.
A Network-based Edge Translator "on a stick" A Network-based Edge Relay "On A Stick"
[IPv4 Internet] [IPv6 Internet] [IPv4 Internet] [IPv6 Internet]
| | | |
+--|--<SIIT-DC GW>--+ | +-----|-----+ |
| [XLAT] | | | (BR/XLAT) | |
+--|----------------+ | +-----|-----+ |
| | | |
[IPv6-only data centre network] [IPv6-only IDC network]
| |
| +--<ET>------+ | +-------------+
| | ____ | | | _IPv6_ |
| | / \ | | | / \ |
+==== [XLAT] | +==== (ER/XLAT) |
| | \____/ | | | \_ _/ |
| | | | | IPv4 | +--<Dual stack node/server>--+
| +------------+ | +-------------+ | +----------------+|
| | | /---AF_INET Dual-stack ||
[Dual-stack network segment] [Dual-stack network segment]----< | Application ||
| | \--AF_INET6 Software ||
+--|--<Dual-stack server>----+ | +----------------+|
| | +----------------+| +----------------------------+
| +---AF_INET Dual-stack ||
| | | Application ||
| \--AF_INET6 Software ||
| +----------------+|
+----------------------------+
Figure 3 Figure 3
Yet another variation would be to implement the ET so that it The ER "On A Stick" approach illustrated in Figure 3 ensures that the
transparently passes IPv6 traffic between its downstream and upstream dual-stack capable node retains native IPv6 connectivity by
network ports unmodified, e.g., using Layer-2 bridging. Packets sent connecting the ER's IPv4 and IPv6 interfaces to the same network
to its own IPv6 Service Addresses from the upstream network are segment, alternatively by using a single dual-stacked interface.
intercepted (e.g, by responding to IPv6 Neighbor Discovery [RFC4861] Native IPv6 traffic between the IDC network and the node bypasses the
messages for them) and routed through the translation function, and ER entirely, while IPv4 traffic from the node will be routed directly
forwarded out its downstream interface. The downstream network to the ER (because it acts as its default IPv4 router), where it is
segment is thus becomes dual-stacked. This model is shown in Figure translated to IPv6 before being transmitted to the upstream default
4. IPv6 router. The ER could attract inbound traffic to the IPv6
Service Addresses by responding to the upstream router's IPv6
A Transparent Network-based Edge Translator Neighbor Discovery [RFC4861] messages for them.
[IPv4 Internet] [IPv6 Internet]
| |
+--|--<SIIT-DC GW>--+ |
| [XLAT] | |
+--|----------------+ |
| |
[IPv6-only data centre network]
|
+--|--<Edge Translator>--+
| |\_____________ |
| | \ |
| [Bridged IPv6] [XLAT] |
| | _____________/ |
| |/ |
+--|---------------------+
|
[Dual-stack network segment]
|
+--|--<Dual-stack server>----+
| | +----------------+|
| +---AF_INET Dual-stack ||
| | | Application ||
| \--AF_INET6 Software ||
| +----------------+|
+----------------------------+
Figure 4
4. Detailed Topology Example
The following figure shows how an application (that is presumably 3.2.2. Edge Router that Bridges IPv6 Packets
incompatible with standard SIIT-DC) is being made available to the
IPv4 Internet on the IPv4 address 192.0.2.4. The application will be
able to know that this is its local address and thus be able to
provide correct references to it in application payload.
The figure also shows how the same application is available over IPv6 A Network-based Edge Relay containing an IPv6 Bridge
on its IPv6 Service Address 2001:db8:12:34::3. This is included in
order to illustrate how native IPv6 connectivity is not impacted by
the Edge Translator, and also to illustrate how the address assigned
to the ET (2001:db8:12:34::4) is separate from the primary IPv6
address of the server. It is however important to note that the
application in question does not have to be dual-stack capable at
all. IPv4-only applications would also be able to operate behind an
ET in the exact same manner.
Note that the figure below could be considered a more detailed view [IPv4 Internet] [IPv6 Internet]
of Customer A's FTP server from the example topology figure in | |
Appendix A of [I-D.ietf-v6ops-siit-dc]. Both figures intentionally +-----|-----+ |
use the exact same example IP addresses and prefixes. | (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 ||
| +----------------+|
+----------------------------+
SIIT-DC Host Architecture with Edge Translation Figure 4
+-------------------+ +----------------+ The ER illustrated in Figure 4 will transparently bridge IPv6 frames
| IPv6-capable user | | IPv4-only user | between its upstream and downstream interfaces. IPv6 packets
| ================= | | ============== | addressed the ER's own IPv6 Service Addresses from the upstream IDC
| | | | network are intercepted (e.g., by responding to IPv6 Neighbor
+-<2001:db8::ab:cd>-+ +-<203.0.113.50>-+ Discovery [RFC4861] messages for them) and routed through the
| | translation function before being forwarded out its downstream
(the IPv6 internet) (the IPv4 Internet) interface as IPv4 packets. The downstream network segment thus
| | becomes dual-stacked.
| +------------------<192.0.2.0/24>-+
| | |
| | SIIT-DC Gateway |
| | =============== |
| | |
| | Translation Prefix: |
| | 2001:db8:46::/96 |
| | |
| | Static Address Mapping: |
| | 192.0.2.4 <=> 2001:db8:12:34::4 |
| | |
| +--------------<2001:db8:46::/96>-+
| |
(the IPv6-only data centre network)
| |
+--<2001:db8:12:34::3>-------<2001:db8:12:34::4>---+
| | | |
| | IPv6-only server | |
| | ================ | |
| | | |
| | +-------------<2001:db8:12:34::4>-+ |
| | | | |
| | | Edge Translator | |
| | | =============== | |
| | | | |
| | | Translation Prefix: | |
| | | 2001:db8:46::/96 | |
| | | | |
| | | Static Address Mapping: | |
| | | 192.0.2.4 <=> 2001:db8:12:34::4 | |
| | | | |
| | +---------------------<192.0.2.4>-+ |
| | | |
| +-[2001:db8:12:34::3]--------------[192.0.2.4]-+ |
| | AF_INET6 AF_INET | |
| | | |
| | Dual-stacked application | |
| | | |
| +----------------------------------------------+ |
+--------------------------------------------------+
Figure 5
5. Deployment Considerations 4. Deployment Considerations
5.1. IPv6 Path MTU 4.1. IPv6 Path MTU
The IPv6 Path MTU between the Edge Translator and the SIIT-DC Gateway The IPv6 Path MTU between the ER and the BR will typically be larger
will typically be larger than the default value defined in Section 4 than the default value defined in Section 4 of [RFC6145] (1280), as
of [RFC6145] (1280), as it will typically contained within a single it will typically contained within a single administrative domain.
administrative domain. Therefore, it is recommended that the IPv6 Therefore, it is RECOMMENDED that the IPv6 Path MTU configured in the
Path MTU configured in the ET is raised accordingly. It is ER is raised accordingly. It is RECOMMENDED that the ER and the BR
RECOMMENDED that the ET and the SIIT-DC Gateway use identical use identical configured IPv6 Path MTU values.
configured IPv6 Path MTU values.
5.2. IPv4 MTU 4.2. IPv4 MTU
In order to avoid IPv6 fragmentation, an Edge Translator should In order to avoid IPv6 fragmentation, an ER SHOULD ensure that the
ensure that the IPv4 MTU used by applications or hosts is equal to IPv4 MTU used by applications or nodes is equal to the configured
the configured IPv6 Path MTU - 20, so that an maximum-sized IPv4 IPv6 Path MTU - 20, so that an maximum-sized IPv4 packet can fit in
packet can fit in an unfragmented IPv6 packet. This ensures that the an unfragmented IPv6 packet. This ensures that the application may
application may do its part in avoiding IP-level fragmentation from do its part in avoiding IP-level fragmentation from occurring, e.g.,
occurring, e.g., by segmenting/fragmenting outbound packets at the by segmenting/fragmenting outbound packets at the application layer,
application layer, and advertising the maximum size its peer may use and advertising the maximum size its peer may use for inbound packets
for inbound packets (e.g., through the use of the TCP MSS option). (e.g., through the use of the TCP MSS option).
A host-based ET could accomplish this by configuring this MTU value A node-based ER could accomplish this by configuring this MTU value
on the virtual network adapter, while a network-based ET could do so on the virtual network adapter, while a network-based ER could do so
by advertising the MTU to its downstream hosts using the DHCPv4 by advertising the MTU to its downstream nodes using the DHCPv4
Interface MTU Option [RFC2132]. Interface MTU Option [RFC2132].
5.3. IPv4 Identification Header 4.3. IPv4 Identification Header
If the generation of IPv6 Atomic Fragments is disabled, the value of If the generation of IPv6 Atomic Fragments is disabled, the value of
the IPv4 Identification header will be lost during the translation. the IPv4 Identification header will be lost during the translation.
Conversely, enabling the generation of IPv6 Atomic Fragments will Conversely, enabling the generation of IPv6 Atomic Fragments will
ensure that the IPv4 Identification Header will carried end-to-end. ensure that the IPv4 Identification Header will carried end-to-end.
Note that for this to work bi-directionally, IPv6 Atomic Fragment Note that for this to work bi-directionally, IPv6 Atomic Fragment
generation must be enabled on both the SIIT-DC Gateway(s) and on the generation MUST be enabled on both the BR and the ER.
Edge Translator.
Note that apart from certain diagnostic tools, there are few (if any) Apart from certain diagnostic tools, there are few (if any)
application protocols that make use of the IPv4 Identification application protocols that make use of the IPv4 Identification
header. Therefore, the loss of the IPv4 Identification value will header. Therefore, the loss of the IPv4 Identification value will
therefore generally not cause any problems. therefore generally not cause any problems.
IPv6 Atomic Fragments and their impact on the IPv4 Identification IPv6 Atomic Fragments and their impact on the IPv4 Identification
header is further discussed in Section 4.8.2 of header is further discussed in Section 4.9.2 of
[I-D.ietf-v6ops-siit-dc]. [I-D.ietf-v6ops-siit-dc].
6. Intra-DC IPv4 Communication 5. Intra-IDC IPv4 Communication
While SIIT-DC is primarily intended to facilitate communication
between IPv4-only nodes on the Internet and services hosted in an
IPv6-only network, it is also possible to facilitate communication
between an IPv4-only service or application running behind an Edge
Translator and another service/application made available over IPv4
through SIIT-DC. This other service/application may be a IPv6-only
service, or it may also be an IPv4-only service running behind
another ET.
Facilitating such communication requires that another Static Address
Mapping is configured in the ET (one for each service it wants to
communicate to). If there are two ETs involved, both of them must be
configured in the same fashion for bi-directional communication to
work. The following two subsections contain examples that
demonstrate how this may be set up.
Note that for the intra-DC communication described in this section,
the SIIT-DC Gateway is not involved at all. Therefore there is no
requirement that the Static Address Mappings in question are also
configured on the SIIT-DC Gateway. It is also possible to use
private [RFC1918] IPv4 addresses, in order to reduce the need for
publicly routable IPv4 addresses. However, if the IPv4-only
application(s) are also to be made available to the IPv4 Internet
through an SIIT-DC Gateway, it is highly recommended that the Static
Address Mappings configured in the ET match those configured in the
SIIT-DC Gateway. Otherwise one end up in the situation where a
service is reached using different IPv4 addresses depending on
whether one connects to it from the IPv4 Internet or from another
IPv4-only application residing in the same data centre. While it may
still work, the overall architecture gets significantly more complex.
Finally, if both services/applications support IPv6, it is highly
recommended that IPv6 is used for all internal communications. The
approach described in this section should only be used if one or both
of the services or applications only supports IPv4, making native
IPv6 communication impossible.
6.1. Between IPv4-Only and IPv6-Only Services
This section demonstrates how an IPv4-only service/application "A"
running behind an ET can communicate with an IPv6-only service "B".
Intra-DC IPv4-only to IPv6-only Overview
/--------------------------------------\ Although SIIT-DC is primarily intended to facilitate communication
| IPv6-only data centre network | 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 so
+--<2001:db8:6::>----------------+ +--<2001:db8:7::>----------------+ through the ER, as it will typically be incapable to contact IPv6
| | | | | | destinations directly. The following subsections discusses various
| | IPv6-only server A | | | IPv6-only server B | methods on how to facilitate such communication.
| | ================== | | | ================== |
| | | | | |
|+-<2001:db8:6::>---------------+| |+-[2001:db8:7::]---------------+|
|| || || AF_INET6 ||
|| Edge Translator A || || ||
|| ================= || || IPv6-only application B ||
|| || |+------------------------------+|
|| Static Address Mappings: || +--------------------------------+
|| 192.0.2.6 <=> 2001:db8:6:: ||
|| 192.0.2.7 <=> 2001:db8:7:: ||
|| ||
|+-<192.0.2.6>------------------+|
| | |
|+-[192.0.2.6]------------------+|
|| AF_INET ||
|| ||
|| IPv4-only application A ||
|+------------------------------+|
+--------------------------------+
Figure 6 5.1. Hairpinning by the SIIT-DC Border Relay
If the BR supports hairpinning as described in Section 4.2 of I-D
.ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam], the easiest solution
is 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.
In this example, the IPv4-only application on server "A" is listening This allows the IPv4-only node or application to transmit packets
on the IPv4 address 192.0.2.6, which is made available to the IPv6 destined for the target service's IPv4 Service Address, which the ER
network on the IPv6 address 2001:db8:6:: (by the ET). The IPv6-only will then translate to a corresponding IPv4-converted IPv6 address by
application on server "B" is only listening on the IPv6 address inserting the Translation Prefix [RFC6052]. When this IPv6 packet
2001:db8:7::, and has no knowledge of IPv4. 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.
In order to facilitate communication between the two application, Hairpinned IPv4-IPv4 packet flow
another Static Address Mapping must be configured in the ET on server
"A". This provides an IPv4 address (192.0.2.7) that the IPv4-only
application can communicate with, which represents the IPv6 address
used by application "B" (2001:db8:7::).
The following figure shows the packet translations step by step, for +-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]-------------+
a packet sent by the IPv4-only application "A" to the IPv6-only | SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |
application "B". For traffic in the opposite direction, you may read | DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:46::192.0.2.2 |---\
the figure from the bottom up and swap the Src/Dst addresses. +---------------+ +----------------------------+ |
(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:: |<--/
+---------------+ +----------------------------+
Intra-DC IPv4-only to IPv6-only Packet Flow Figure 5
(IPv4-only application A) --\ 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
Src 192.0.2.6 | ER B. ER A is configured with the EAM {192.0.2.1,2001:db8:a::}, ER B
Dst 192.0.2.7 | Packet forwarding/translations with {192.0.2.2,2001:db8:b::}. The BR is configured with both EAMs,
| | happening inside server A and supports hairpinning. Note that if the target service had not
V | been located behind an ER, the third and final translation (XLAT#3)
[SIIT-DC ET A] | would not have happened, i.e., the target service/node would have
| --/ received and responded to packet #3 directly.
| --\
Src 2001:db8:6:: | Actual IPv6 packets routed
Dst 2001:db8:7:: | through the IPv6 network
| --/
V
(IPv6-only application B)
Figure 7 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.
6.2. Between Two IPv4-Only Services 5.2. Additional EAMs Configured in Edge Relay
This section demonstrates how an IPv4-only service/application "A" If the BR does not support hairpinning, or if the hairpinning
running behind an ET can communicate with an IPv4-only service/ solution is not desired for some other reason, intra-IDC IPv4 traffic
application "B" running behind another ET. 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.
Intra-DC IPv4-only to IPv6-only Overview 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 this to an IPv6 packet with the local
application/node's own IPv6 Service Address as source and the target
service's IPv6 Service Address as the destination, and forward this
to the IPv6 network. Replies from the target service will undergo
these translations in reverse.
/--------------------------------------\ If the target service is also located behind another ER, that other
| IPv6-only data centre network | ER MUST also be provisioned with an additional EAM that contains the
\-+----------------------------------+-/ origin IPv4-only application/node's IPv4 and IPv6 Service Addresses.
| | Otherwise, the target service's ER will be unable to translate the
| | source address of the incoming packets.
+--<2001:db8:8::>----------------+ +--<2001:db8:9::>----------------+
| | | | | |
| | IPv6-only server A | | | IPv6-only server B |
| | ================== | | | ================== |
| | | | | |
|+-<2001:db8:8::>---------------+| |+-<2001:db8:9::>---------------+|
|| || || ||
|| Edge Translator A || || Edge Translator B ||
|| ================= || || ================= ||
|| || || ||
|| Static Address Mappings: || || Static Address Mappings: ||
|| 192.0.2.8 <=> 2001:db8:8:: || || 192.0.2.8 <=> 2001:db8:8:: ||
|| 192.0.2.9 <=> 2001:db8:9:: || || 192.0.2.9 <=> 2001:db8:9:: ||
|| || || ||
|+-<192.0.2.8>------------------+| |+-<192.0.2.9>------------------+|
| | | | | |
|+-[192.0.2.8]------------------+| |+-[192.0.2.9]------------------+|
|| AF_INET || || AF_INET ||
|| || || ||
|| IPv4-only application A || || IPv4-only application B ||
|+------------------------------+| |+------------------------------+|
+--------------------------------+ +--------------------------------+
Figure 8 Non-hairpinned IPv4-IPv4 packet flow
In this example, the IPv4-only application on server "A" is listening +-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]---+
on the IPv4 address 192.0.2.8, which is made available to the IPv6 | SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |
network on the IPv6 address 2001:db8:8:: (by the ET). In the same | DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:b:: |
fashion, the IPv4-only application on server "B" is listening on the +---------------+ +------------------+
IPv4 address 192.0.2.9 and is made available by its ET on the IPv6 |
address 2001:db8:9::. +-[Pkt#3: IPv4]-+ |
| SRC 192.0.2.1 | (XLAT#2) |
| DST 192.0.2.2 |<-------(@ ER B)------/
+---------------+
In order to facilitate communication between the two application, a Figure 6
second Static Address Mapping must be configured in the ET on both
servers. This provides each application with an IPv4 address that
represents the other application. Thus bi-directional communication
between the two applications can commence.
The following figure shows the packet translations step by step, for Figure 6 illustrates the flow of a packet carrying intra-IDC IPv4
a packet sent by the IPv4-only application "A" to the IPv4-only traffic between two IPv4-only nodes/applications that are both
application "B". For traffic in the opposite direction, you may read located behind ERs. Both ER A and ER B are configured with two EAMs:
the figure from the bottom up and swap the Src/Dst addresses. {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.
Intra-DC IPv4-only to IPv4-only Packet Flow 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.
(IPv4-only application A) --\ Note that if the target service in this example was not located
| | behind an ER, but instead was a native IPv6 service listening on
Src 192.0.2.8 | 2001:db8:b::, the second translation step in Figure 6 would not
Dst 192.0.2.9 | Packet forwarding/translations occur; the target service would receive and respond to packet #2
| | happening inside server A directly.
V |
[SIIT-DC ET A] |
| --/
| --\
Src 2001:db8:8:: | Actual IPv6 packets routed
Dst 2001:db8:9:: | through the IPv6 network
| --/
V --\
[SIIT-DC ET B] |
| |
Src 192.0.2.8 | Packet forwarding/translations
Dst 192.0.2.9 | happening inside server B
| |
V |
(IPv4-only application B) --/
Figure 9 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].
7. Acknowledgements 6. Acknowledgements
The author would like to especially thank the authors of 464XLAT The author would like to especially thank the authors of 464XLAT
[RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne. [RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne.
The architecture described by this document is merely an adaptation The architecture described by this document is merely an adaptation
of their work to a data centre environment, and could not have of their work to a data centre environment, and could not have
happened without them. happened without them.
The author would like also to thank the following individuals for The author would like also to thank the following individuals for
their contributions, suggestions, corrections, and criticisms: Fred their contributions, suggestions, corrections, and criticisms: Fred
Baker, Tobias Brox, Ray Hunter, Shucheng LIU (Will), Andrew Baker, Tobias Brox, Ray Hunter, Shucheng LIU (Will), Andrew
Yourtchenko. Yourtchenko.
8. IANA Considerations 7. IANA Considerations
This draft makes no request of the IANA. The RFC Editor may remove This draft makes no request of the IANA. The RFC Editor may remove
this section prior to publication. this section prior to publication.
9. Security Considerations 8. Security Considerations
This section discusses security considerations specific to the use of This section discusses security considerations specific to the use of
an Edge Translator. See the Security Considerations section in an ER. See the Security Considerations section in
[I-D.ietf-v6ops-siit-dc] for additional security considerations [I-D.ietf-v6ops-siit-dc] for additional security considerations
applicable to the SIIT-DC architecture in general. applicable to the SIIT-DC architecture in general.
9.1. Address Spoofing 8.1. Address Spoofing
If the ER receives an IPv4 packet from the application/node from a
If the ET receives an IPv4 packet from the application from a source address it does not have an EAM for, both the source and
different source address than the one it has a Static Address Mapping destination addresses will be rewritten according to [RFC6052].
for, the both the source and destination addresses will be rewritten After undergoing the reverse translation in the BR, the resulting
according to [RFC6052]. After undergoing the reverse translation in IPv4 packet routed to the IPv4 network will have a spoofed IPv4
the SIIT-DC Gateway, the resulting IPv4 packet routed to the IPv4 source address. The ER SHOULD therefore ensure that ingress
network will have a spoofed IPv4 source address. The ET should filtering [RFC2827] is used on the ER's IPv4 interface, so that such
therefore ensure that ingress filtering (cf. BCP38 [RFC2827]) is used packets are immediately discarded.
on the ET's IPv4 interface, so that such packets are immediately
discarded.
If the ET receives an IPv6 packet with both the source and If the ER receives an IPv6 packet with both the source and
destination address equal to the one it has a Static Address Mapping destination address equal to one of its local IPv6 Service Addresses,
for, the resulting packet would appear to the application as locally the resulting packet would appear to the IPv4-only application/node
generated, as both the source address and the destination address as locally generated, as both the source address and the destination
will be the same address as the one configured on the virtual IPv4 address will be the same address. This could trick the application
interface. This could trick the application into thinking this into believing the packet came from a trusted source (itself). To
packet came from a trusted source, and give elevated privileges prevent this, the ER SHOULD discard any received IPv6 packets that
accordingly. To prevent this, the ET should discard any received have a source address that is either 1) equal to any of its local
IPv6 packets that have a source address that is equal either to IPv6 Service Addresses, or 2) after translation from IPv6 to IPv4,
either the IPv4 (after undergoing [RFC6052] translation) or the IPv6 equal to any of its local IPv4 Service Addresses.
address in the Static Address Mapping.
10. References 9. References
10.1. Normative References 9.1. Normative References
[I-D.ietf-v6ops-siit-dc] [I-D.ietf-v6ops-siit-dc]
tore, t., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
Data Centre Environments", draft-ietf-v6ops-siit-dc-00 IPv6 Data Centre Environments", draft-ietf-v6ops-siit-
(work in progress), December 2014. dc-00 (work in progress), December 2014.
[I-D.ietf-v6ops-siit-eam]
Anderson, T. and A. Leiva, "Explicit Address Mappings for
Stateless IP/ICMP Translation", draft-ietf-v6ops-siit-
eam-00 (work in progress), May 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 9.2. Informative References
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC Combination of Stateful and Stateless Translation", RFC
6877, April 2013. 6877, April 2013.
Author's Address [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335,
August 2014.
Appendix A. Examples: Network-Based IPv4 Connectivity
A.1. Subnet with IPv4 Service Addresses
One relatively straight-forward way to provide IPv4 connectivity
between the 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. The ER may then proceed
to 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 [RFC0826],
instead of sending them to the ER for translation to IPv6. This
problem could however be overcome by avoiding assigning IPv4 Service
Addresses which overlaps with an IPv4 prefix handled by an ER (at the
expense of wasting some potential IPv4 Service Addresses), or by
ensuring that the overlapping IPv6 Service Addresses are only
assigned to services which 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 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.
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.
Authors' Addresses
Tore Anderson Tore Anderson
Redpill Linpro Redpill Linpro
Vitaminveien 1A Vitaminveien 1A
0485 Oslo 0485 Oslo
Norway Norway
Phone: +47 959 31 212 Phone: +47 959 31 212
Email: tore@redpill-linpro.com Email: tore@redpill-linpro.com
URI: http://www.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
 End of changes. 91 change blocks. 
599 lines changed or deleted 499 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/