One document matched: draft-anderson-v6ops-siit-dc-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-anderson-v6ops-siit-dc-00"
ipr="trust200902">
<front>
<title abbrev="SIIT-DC">SIIT-DC: Stateless IP/ICMP Translation for IPv6
Data Centre Environments</title>
<author fullname="Tore Anderson" initials="T.A." surname="Anderson">
<organization>Redpill Linpro</organization>
<address>
<postal>
<street>Vitaminveien 1A</street>
<city>0485 Oslo</city>
<country>NORWAY</country>
</postal>
<phone>+47 959 31 212</phone>
<email>tore@redpill-linpro.com</email>
</address>
</author>
<date year="2014" />
<area>General</area>
<workgroup>IPv6 Operations</workgroup>
<abstract>
<t>
This document describes SIIT-DC, an extension to <xref target="RFC6145">
Stateless IP/ICMP Translation (SIIT)</xref> that makes it ideally suited
for use in IPv6 data centre environments. SIIT-DC simultaneously
facilitates IPv6 deployment and IPv4 address conservation. The overall
SIIT-DC architecture is described, as well as guidelines for operators.
Finally, the normative implementation requirements are described, as a
list of additions and changes to <xref target="RFC6145">SIIT</xref>.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
SIIT-DC is an extension of <xref target="RFC6145">SIIT</xref>, and
provides a a network-centric stateless translation service that allows a
data centre operator or Internet Content Provider (ICP) to run a data
centre network, servers, and applications using exclusively IPv6, while
at the same time ensuring that end users that have only IPv4
connectivity will be able to continue to access the services and
applications.
</t>
<section title="Motivation and Goals">
<t>
Historically, <xref target="RFC4213">dual stack</xref> has been the
recommended way to transition from an IPv4-only environment to one
capable of serving IPv6 users. For data centre and Internet content
providers, dual stack operation has a number of disadvantages compared
to single stack operation. In particular, the increased complexity and
operational overhead, and very low expected return of investment in
the short to medium term, as there are practically no end-users who
have only connectivity to the IPv6 Internet. Furthermore, the dual
stack approach does not in any way help with the depletion of the IPv4
address space.
</t>
<t>
Therefore, a better approach is needed. The design goals are:
</t>
<t>
<list style="symbols">
<t>Promote the deployment of native IPv6 services (cf. <xref
target="RFC6540"/>).</t>
<t>Provide IPv4 service availability for legacy users with no loss
of performance or functionality.</t>
<t>To ensure that that the legacy users' IPv4 addresses remain
available to the servers and applications.</t>
<t>To conserve and maximise the utilisation of IPv4 addresses.</t>
<t>To avoid introducing more complexity than absolutely necessary,
especially on the servers and applications.</t>
<t>To be easy to scale and deploy in a fault-tolerant manner.</t>
</list>
</t>
<t>
The following subsections elaborates on how SIIT-DC meets these goals.
</t>
<section title="Single Stack IPv6 Operation">
<t>
SIIT-DC allows an operator to build their applications on an
IPv6-only foundation. IPv4 end-user connectivity becomes a service
provided by the network, which systems administration and
application development staff do not need to concern themselves
with.
</t>
<t>
Obviously, this will promote universal IPv6 deployment for all of
the provider's services and applications.
</t>
<t>
It is worth noting that SIIT-DC requires no special support or
change from the underlying IPv6 infrastructure, it will work with
any kind of IPv6 network. Traffic between IPv6-enabled end users and
IPv6-enabled services will always be native, and SIIT-DC will not be
involved in it at all.
</t>
</section>
<section title="Stateless Operation">
<t>
Unlike other solutions that provide either dual stack availability
to single-stack services (e.g., <xref target="RFC6146">Stateful
NAT64</xref> and Layer-4/7 proxies), or that provide conservation of
IPv4 addresses (e.g., <xref target="RFC3022">NAPT44</xref>), a
SIIT-DC Gateway does not keep any state between each packet in a
single connection or flow. In this sense it operates exactly like a
normal IP router, and has similar scaling properties - the limiting
factors are packets per second and bandwidth. The number of
concurrent flows and flow initiation rates are irrelevant for
performance.
</t>
<t>
This not only allows individual SIIT-DC Gateways to easily attain
"line rate" performance, it also allows for per-packet load
balancing between multiple SIIT-DC Gateways using <xref
target="RFC2991">Equal-Cost Multipath Routing</xref>. Asymmetric
routing is also acceptable, which makes it easy to avoid sub-optimal
traffic patterns; the prefixes involved may be anycasted from all
the SIIT-DC Gateways in the provider's network, thus ensuring that
the most optimal path through the network is used, even where the
optimal path in one direction differs from the optimal path in the
opposite direction.
</t>
<t>
Finally, stateless operation means that high availability is easily
achieved. If an SIIT-DC Gateway should fail, its traffic can be
re-routed onto another SIIT-DC Gateway using a standard IP routing
protocol. This does not impact existing flows any more than what any
other IP re-routing event would.
</t>
</section>
<section title="No Loss of End User's Source Address">
<t>
SIIT-DC will map the entire end-user's source address into an
predefined IPv6 translation prefix. This allows the application
server to identify the user by an IPv4 address, which is useful for
performing tasks like Geo-Location, logging, abuse handling, and so
forth.
</t>
</section>
<section title="No Forklift Upgrades Required">
<t>
Except for the introduction of the SIIT-DC Gateways themselves,
there is no change required in the network, servers, applications,
or anywhere else to specifically support SIIT-DC, compared to a dual
stack deployment. From the clients', the servers', the IPv6 data
centre network's, and the IPv4 Internet's point of view, SIIT-DC is
practically invisible. It will work with any standards-compliant
IPv4 or IPv6 stack.
</t>
</section>
<section title="No Architectural Dependency on IPv4">
<t>
SIIT-DC will allow an ICP or data centre operator to build
infrastructure and applications entirely on IPv6. This means that
when the day comes to discontinue support for IPv4, no change needs
to be made to the overall architecture - it's only a matter of
shutting off the SIIT-DC Gateways. Therefore, by deploying native
IPv6 along with SIIT-DC, operators will avoid future migration or
deployment projects relating to IPv6 roll-out and/or IPv4
sun-setting.
</t>
</section>
</section>
</section>
<section anchor="terminology" title="Terminology">
<t>
This document makes use of the following terms:
</t>
<t>
<list style="hanging">
<t hangText="IPv4 Service Address">A public IPv4 address with which
IPv4-only clients will communicate. This communication will be
translated to IPv6 by the SIIT-DC Gateway.</t>
<t hangText="IPv4 Service Address Pool">One or more IPv4 prefixes
routed to the SIIT-DC Gateway's IPv4 interface. IPv4 Service Addresses
are allocated from this pool. Note that this does not necessarily have
to be a "pool" per se, as it could also be one or more host routes
(whose prefix length is equal to /32). The primary purpose of using a
pool rather than host routes is to facilitate IPv4 route aggregation
and ease provisioning of new IPv4 Service Addresses.</t>
<t hangText="IPv6 Service Address">A public IPv6 address assigned to a
server or application in the IPv6 network. IPv6-only and dual stacked
clients communicates with this address directly without invoking
SIIT-DC. IPv4-only clients also communicates with this address through
the SIIT-DC Gateway and via an IPv4 Service Address.</t>
<t hangText="SIIT-DC Host Agent">A logical function very similar to an
SIIT-DC Gateway that resides on a server and provides virtual IPv4
connectivity to applications, by reversing the translations done by the
SIIT-DC Gateway. It is an optional component of the SIIT-DC
architecture, that may be used to increase application support. See
<xref target="I-D.anderson-v6ops-siit-dc-2xlat"/>.</t>
<t hangText="SIIT-DC Gateway">A device or a logical function that
translates between IPv4 and IPv6 in accordance with <xref
target="implementation_reqs"/>.</t>
<t hangText="Static Address Mapping">A bi-directional mapping between
an IPv4 Service Address and an IPv6 Service Address configured in the
SIIT-DC Gateway. When translating between IPv4 and IPv6, the SIIT-DC
Gateway changes the address fields in the translated packet's IP header
according to any matching Static Address Mapping.</t>
<t hangText="Translation Prefix">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 is either an Network-Specific Prefix or a
Well-Known Prefix as specified in <xref target="RFC6052"/>. When
translating between IPv4 and IPv6, the SIIT-DC Gateway prepends or
strips the Translation Prefix from the address fields in the translated
packet's IP header, unless a Static Address Mapping exists for the IP
address in question.</t>
</list>
</t>
</section>
<section anchor="overview" title="Architectural Overview">
<t>
This section describes the basic SIIT-DC architecture.
<figure anchor="fig_architecture" align="center">
<preamble>SIIT-DC Architecture</preamble>
<artwork align="center"><![CDATA[
+-------------------+ +----------------+
| IPv6-capable user | | IPv4-only user |
| ================= | | ============== |
| | | |
+-<2001:db8::ab:cd>-+ +-<203.0.113.50>-+
| |
| |
(the IPv6 internet) (the IPv4 Internet)
| |
| |
| +------------------<192.0.2.0/24>-+
| | |
| | SIIT-DC Gateway |
| | =============== |
| | |
| | Translation Prefix: |
| | 2001:db8:46::/96 |
| | |
| | Static Address Mapping: |
| | 192.0.2.1 <=> 2001:db8:12:34::1 |
| | |
| +--------------<2001:db8:46::/96>-+
| |
| |
(the IPv6-only data centre network)
| |
| ------------------------------/
|/
|
+--<2001:db8:12:34::1>------------------------------+
| | |
| | IPv6-only server |
| | ================ |
| | |
| +-[2001:db8:12:34::1]---------------------------+ |
| | AF_INET6 | |
| | | |
| | IPv6-only application | |
| | | |
| +-----------------------------------------------+ |
+---------------------------------------------------+
]]></artwork>
</figure>
</t>
<t>
In this example, 192.0.2.0/24 is allocated as an IPv4 Service Address
Pool. Individual IPv4 Service Addresses are assigned from this pool.
The provider must route this prefix to the SIIT-DC Gateway's IPv4
interface. Note that there are no restrictions on how many IPv4 Service
Address Pools are used or their prefix length, as long as they are all
routed to the SIIT-DC Gateway's IPv4 interface.
</t>
<t>
The Static Address Mapping list is used when translating an IPv4 Service
Address (here 192.0.2.1) to its corresponding IPv6 Service Address (here
2001:db8:12:34::1) and vice versa. When the SIIT-DC Gateway translates
an IPv4 packet to IPv6, any IPv4 Service Address found in the original
IPv4 header will be replaced with the corresponding IPv6 Service Address
in the resulting IPv6 header, and vice versa when translating an IPv6
packet to IPv4.
</t>
<t>
2001:db8:46::/96 is the Translation Prefix into which the entire IPv4
address space is mapped. It is used for translation of the end user's
IPv4 address to IPv6 and vice versa according to the algorithm defined
in <xref target="RFC6052">Section 2.2 of RFC6052</xref>. This
algorithmic mapping has a lower precedence than the configured Static
Address Mappings.
</t>
<t>
The SIIT-DC Gateway itself can be either a separate device or a logical
function in another multi-purpose device, for example an IP router. Any
number of SIIT-DC Gateways may exist simultaneously in an operators
infrastructure, as long as they all have the same translation prefix and
list of Static Mappings configured.
</t>
<section title="DNS Configuration">
<t>
The IPv6 Service Address of should be registered in DNS using an AAAA
record, while its corresponding IPv4 Service Address should be
registered using an A record. This results in the following DNS
records:
</t>
<t>
<figure anchor="fig_dnsconfig" align="center">
<preamble>DNS Configuration for a SIIT-DC enabled service</preamble>
<artwork align="center"><![CDATA[
app.domain.tld. IN AAAA 2001:db8:12:34::1
app.domain.tld. IN A 192.0.2.1
]]></artwork>
</figure>
</t>
</section>
<section title="Packet Flow">
<t>
In this example, "IPv4-only user" initiates a request to the
application running on the IPv6-only server. He starts by looking up
the IN A record of "app.domain.tld" in DNS, and attempts to connect to
this address on the service by transmitting the following IPv4 packet
destined for the IPv4 Service Address:
</t>
<t>
<figure anchor="fig_xlat_s1" align="center">
<preamble>Stage 1: Client -> Server, IPv4</preamble>
<artwork align="center"><![CDATA[
+------------------------------------------------+
| IP Version: 4 |
| Source Address: 203.0.113.50 |
| Destination Address: 192.0.2.1 |
| Protocol: TCP |
|------------------------------------------------|
| TCP SYN [...] |
+------------------------------------------------+
]]></artwork>
</figure>
</t>
<t>
This packet is then routed over the Internet to the (nearest) SIIT-DC
Gateway, which translates it into the following IPv6 packet and
forward it into the IPv6 network:
</t>
<t>
<figure anchor="fig_xlat_s2" align="center">
<preamble>Stage 2: Client -> Server request, IPv4</preamble>
<artwork align="center"><![CDATA[
+-------------------------------------------------+
| IP Version: 6 |
| Source Address: 2001:db8:46::203.0.113.50 |
| Destination Address: 2001:db8:12:34::1 |
| Next Header: TCP |
|-------------------------------------------------|
| TCP SYN [...] |
+-------------------------------------------------+
]]></artwork>
</figure>
</t>
<t>
The destination address field was translated to the IPv6 Service
Address according to the configured Static Address Mapping, while the
source address was field translated according to the <xref
target="RFC6052"/> mapping using the Translation Prefix (because it
did not match any Static Address Mapping). The rest of the IP header
was translated according to <xref target="RFC6145"/>. The Layer 4
payload is copied verbatim, with the exception of the TCP checksum
being recalculated.
</t>
<t>
Note that the IPv6 address 2001:db8:46::203.0.113.50 may also be
expressed as 2001:db8:46::cb00:7132, cf. <xref
target="RFC2373">Section 2.2 of RFC2373</xref>.
</t>
<t>
Next, the application receives receives this IPv6 packet and responds
to it like it would with any other IPv6 packet:
</t>
<t>
<figure anchor="fig_xlat_s3" align="center">
<preamble>Stage 3: Server -> Client response, IPv6</preamble>
<artwork align="center"><![CDATA[
+-------------------------------------------------+
| IP Version: 6 |
| Source Address: 2001:db8:12:34::1 |
| Destination Address: 2001:db8:46::203.0.113.50 |
| Next Header: TCP |
|-------------------------------------------------|
| TCP SYN+ACK [...] |
+-------------------------------------------------+
]]></artwork>
</figure>
</t>
<t>
The response packet is routed to the (nearest) SIIT-DC Gateway's IPv6
interface, which will translate it back to IPv4 as follows:
</t>
<t>
<figure anchor="fig_xlat_s4" align="center">
<preamble>Stage 4: Server -> Client response, IPv4</preamble>
<artwork align="center"><![CDATA[
+------------------------------------------------+
| IP Version: 4 |
| Source Address: 192.0.2.2 |
| Destination Address: 203.0.113.50 |
| Protocol: TCP |
|------------------------------------------------|
| TCP SYN+ACK [...] |
+------------------------------------------------+
]]></artwork>
</figure>
</t>
<t>
This time, the source address matched the Static Address Mapping and
was translated accordingly, while the destination address did not, and
was therefore translated according to <xref target="RFC6052"/> by
having the Translation Prefix stripped. The rest of the packet was
translated according to <xref target="RFC6145"/>.
</t>
<t>
The resulting IPv4 packet is transmitted back to the end user over the
IPv4 Internet. Subsequent packets in the flow will follow the exact
same translation pattern. They may or may not cross the same
translators as earlier packets in the same flow.
</t>
<t>
The end user's IPv4 stack has no idea that it is communicating with an
IPv6 server, nor does the server's IPv6 stack have any idea that is is
communicating with an IPv4 client. To them, it's just plain IPv4 or
IPv6, respectively. However, the applications running on the server
may optionally be updated to recognise and strip the Translation
Prefix, so that the end user's IPv4 address may be used for logging,
Geo-Location, abuse handling, and so forth.
</t>
</section>
</section>
<section title="Deployment Guidelines">
<t>
In this section, we list recommendations and guidelines for operators
who would like to deploy a SIIT-DC service in their data centre network.
</t>
<section title="Application Support for NAT">
<t>
Not all application protocols are able to operate in a network
environment where rewriting of IP addresses occur. An operator should
therefore carefully evaluate the applications he would like to make
available for IPv4 users through SIIT-DC, to ensure they do not fall
in this category. In general, if an application layer protocol works
correctly through standard NAT44 (see <xref target="RFC3235"/>), it
will most likely work correctly through SIIT-DC as well.
</t>
<t>
Higher-level protocols that embed IP addresses as part of their
payload are especially problematic, as noted in <xref
target="RFC2663"/>, <xref target="RFC2993"/>, and <xref
target="RFC3022"/>. Such protocols will most likely not work through
any form of address translation, including SIIT-DC. One well-known
example of such a protocol is <xref target="RFC0959">FTP</xref>.
</t>
<t>
The SIIT-DC architecture may be extended with a Host Agent that
reverses the translation performed by the SIIT-DC Gateway before
passing the packets to the application software. This allows the
problematic application protocols described above to work correctly in
an SIIT-DC environment as well. See <xref
target="I-D.anderson-v6ops-siit-dc-2xlat"/> for a description of this
extension.
</t>
</section>
<section title="Application Support for IPv6">
<t>
SIIT-DC requires that the application software supports IPv6
networking, and that it has no dependency on IPv4 networking. If this
is not the case, the approach described in <xref
target="I-D.anderson-v6ops-siit-dc-2xlat"/> may be used, as it
provides the application with seemingly native IPv4 connectivity. This
allows IPv4-only applications to work correctly in an otherwise
IPv6-only environment.
</t>
</section>
<section title="Application Communication Pattern">
<t>
SIIT-DC is ideally suited for applications where IPv4-only nodes on
the Internet initiate traffic towards the IPv6-only services, which in
turn are only passively listening for inbound traffic and responding
as necessary. One well-known example of such a protocol is <xref
target="RFC2616">HTTP</xref>. This is due to the fact that in this
case, an IPv4 user looks exactly like an ordinary IPv6 user from the
host and application's point of view, and requires no special
treatment.
</t>
<t>
It is possible to combine SIIT-DC with <xref
target="RFC6147">DNS64</xref> in order to allow an IPv6-only
application to initiate communication with IPv4-only nodes through an
SIIT-DC Gateway. However, in this case, care must be taken so that all
outgoing communication is sourced from the IPv6 Service Address that
has a Static Mapping configured on the SIIT-DC Gateway. If another
unmapped address is used, the SIIT-DC Gateway will discard the packet.
</t>
<t>
An alternative approach to the above would be to make use of an
SIIT-DC Host Agent as described in <xref
target="I-D.anderson-v6ops-siit-dc-2xlat"/>. This provides the
application with seemingly native IPv4 connectivity, which it may use
for both inbound and outbound communication without requiring the
application to select a specific source address for its outbound
communications.
</t>
</section>
<section title="Choice of Translation Prefix">
<t>
Either a Network-Specific Prefix (NSP) from the provider's own IPv6
address space or the IANA-allocated Well-Known Prefix 64:ff9b::/96
(WKP) may be used. From a technical point of view, both should work
equally well, however as only a single WKP exists, if a provider would
like to deploy more than one instance of SIIT-DC in his network, or
<xref target="RFC6146">Stateful NAT64</xref>, an NSP must be used
anyway for all but one of those deployments.
</t>
<t>
Furthermore, the WKP cannot be used in inter-domain routing. By using
an NSP, a provider will have the possibility to provide SIIT-DC
service to other operators across Autonomous System borders.
</t>
<t>
For these reasons, this document recommends that an NSP is used.
Section 3.3 of <xref target="RFC6052"/> discusses the choice of
translation prefix in more detail.
</t>
<t>
The Translation Prefix may use any of the lengths described in <xref
target="RFC6052">Section 2.2 of RFC6052</xref>, but /96 has two
distinct advantages over the others. First, converting it to IPv4 can
be done in a single operation by simply stripping off the first 96
bits; second, it allows for IPv4 addresses to be embedded directly
into the text representation of an IPv6 address using the familiar
dotted quad notation, e.g., "2001:db8::198.51.100.10" (cf. <xref
target="RFC6052">Section 2.4 of RFC6052</xref>)), instead of being
converted to hexadecimal notation. This makes it easier to write IPv6
ACLs and similar that match translated endpoints in the IPv4 Internet.
Use of a /96 prefix length is therefore recommended.
</t>
</section>
<section title="Routing Considerations">
<t>
The prefixes that constitute the IPv4 Service Address Pool and the
IPv6 Translation Prefix may be routed to the SIIT-DC Gateway(s) as any
other IPv4 or IPv6 route in the provider's network.
</t>
<t>
If more than one SIIT-DC Gateway is being deployed, it is recommended
that a dynamic routing protocol (such as BGP, IS-IS, or OSPF) is being
used to advertise the routes within the provider's network. This will
ensure that the traffic that is to be translated will reach the
closest SIIT-DC Gateway, reducing or eliminating sub-optimal traffic
patterns, as well as provide high availability - if one SIIT-DC
Gateway fails, the dynamic routing protocol will automatically
redirect the traffic to the next-best translator.
</t>
</section>
<section title="Location of the SIIT-DC Gateways">
<t>
It is optimal to place the SIIT-DC Gateways as close as possible to
the direct path between the servers and the end users. If the closest
translator is located a long way from the optimal path, all packets in
both directions must make a detour. This would increase the RTT
between the server and the end user by by two times the extra latency
incurred by the detour, as well as cause unnecessary load on the
network links on the detour path.
</t>
<t>
The ideal location of the SIIT-DC Gateways would be a logical function
within the IP routers would have handled the traffic anyway (if the
topology was dual stacked) This way, the translation service would not
need separate networks ports to be assigned (which might become
saturated and impact the service quality), nor would it need extra
rack space or energy. Some good choices of the location could be
within a data centre's access routers, or inside the provider's border
routers. If every single application in the data centre or the
provider's network eventually get single-stacked, there would no need
to run IPv4 on the inside of the SIIT-DC Gateway - thus allowing the
operator to reclaim IPv4 addresses from the network infrastructure
that may instead be used for translated services.
</t>
</section>
<section title="Migration from Dual Stack">
<t>
While this document discusses the use of IPv6-only servers and
applications, there is no technical requirement that the servers are
IPv4 free. SIIT-DC works equally well for dual stacked servers, which
makes migration easy - after setting up the translation function, the
DNS A record for the service is updated to point to the IPv4 address
that will be translated to IPv6, the previously used IPv4 service
address may continue to be assigned to the server. This makes
roll-back to dual stack easy, as it is only a matter of changing the
DNS record back to what it was before.
</t>
<t>
For high-volume services migrating to SIIT-DC from dual stack, DNS
Round Robin may be used to gradually migrate the service's IPv4
traffic from its native IPv4 address(es) to the translated IPv4
Service Address(s).
</t>
</section>
<section title="Packet Size and Fragmentation Considerations">
<t>
There are two key differences between IPv4 and IPv6 relating to packet
sizes that one should consider when deploying SIIT-DC. They result in
a few problematic corner cases, which can be dealt with in a few
different ways.
</t>
<t>
The operator may find that relying on fragmentation in the IPv6 domain
is undesired or even operationally impossible <xref
target="I-D.taylor-v6ops-fragdrop"/>. For this reason, the
recommendations in this section seeks to minimise the use of IPv6
fragmentation.
</t>
<t>
Unless otherwise stated, this section assumes that the MTU in both the
IPv4 and IPv6 domains is 1500 bytes.
</t>
<section title="IP Header Size Difference">
<t>
The IPv6 header is up to 20 bytes larger than the IPv4 header. This
means that a full-size 1500 bytes large IPv4 packet cannot be
translated to IPv6 without being fragmented, otherwise it would
likely have resulted in a 1520 bytes large IPv6 packet.
</t>
<t>
If the transport protocol used is TCP, this is generally not a
problem, as the IPv6 server will advertise a TCP MSS of 1440 bytes.
This causes the client to never send larger packets than what can be
translated to a single full-size IPv6 packet, eliminating any need
for fragmentation.
</t>
<t>
For other transport protocols, full-size IPv4 packets with the DF
flag cleared will need to be fragmented by the SIIT-DC Gateway. The
only way to avoid this is to increase the Path MTU between the
SIIT-DC Gateway and the servers to 1520 bytes. Note that the
servers' MTU SHOULD NOT be increased accordingly, as that would
cause them to undergo Path MTU Discovery for most native IPv6
destinations. However, the servers would need to be able to accept
and process incoming packets larger than their own MTU. If the
server's IPv6 implementation allows the MTU to be set differently
for specific destinations, it could be increased to 1520 for
destinations within the Translation Prefix specifically.
</t>
</section>
<section title="Minimum Path MTU Difference">
<t>
The minimum allowed link MTU in IPv6 is 1280 bytes. In IPv4, the
corresponding value is 68 bytes. This means that an 1280 byte large
IPv6 packet sent to an IPv4 client may need to be fragmented by a
router in the IPv4 network, if the path to the IPv4 client involves
a link with a MTU lower than 1260 bytes.
</t>
<t>
By default, an SIIT-DC Gateway will set the DF flag when translating
from IPv6 to IPv4, resulting in a situation where the IPv6 server
may receive an ICMPv6 Packet Too Big error where the indicated MTU
value is less than the IPv6 minimum of 1280. In this situation, the
IPv6 server has two choices on how to proceed, according to the last
paragraph of <xref target="RFC2460">Section 5 of RFC2460</xref>:
</t>
<t>
<list style="symbols">
<t>It may reduce its Path MTU value to the value indicated in the
Packet Too Big. This causes no problems for the SIIT-DC
function.</t>
<t>It may reduce its Path MTU value to exactly 1280, and also
include a Fragmentation header in each subsequent packet sent to
that destination. The Fragmentation header signals to the the
SIIT-DC Gateway that the DF flag should be cleared in the
resulting IPv4 packet, and it also provides the Identification
value.</t>
</list>
</t>
<t>
If the use of the IPv6 Fragmentation header is problematic, and the
operator has IPv6 servers that implement the second option above,
the operator should enable a feature on the SIIT-DC Gateways which
ensures that the resulting MTU field is always set to 1280 or higher
when translating ICMPv4 Need to Fragment into ICMPv6 Packet Too Big,
and that when translating IPv6 packets smaller or equal to 1280
bytes the resulting IPv4 packets will have the DF flag cleared and
an Identification value generated, cf. <xref
target="feat_smallv4pmtu"/>.
</t>
</section>
<section title=""Atomic Fragments"">
<t>
By default, an SIIT-DC Gateway will include a Fragmentation header
in the resulting IPv6 packet when translating from an IPv4 packet
with the DF flag cleared, cf. <xref target="RFC6145">Section 4 of
RFC6145</xref>.
</t>
<t>
This happens even though the resulting IPv6 packet isn't actually
fragmented into several pieces, resulting in an "Atomic Fragment"
<xref target="RFC6946"/>. This is generally not useful in a data
centre environment, and it is therefore recommended that this
behaviour is disabled in the SIIT-DC Gateway(s). See <xref
target="feat_noatomicfrags"/>.
</t>
</section>
</section>
</section>
<section anchor="implementation_reqs" title="Implementation Requirements">
<t>
This normative section specifies the SIIT-DC protocol that is
implemented by an SIIT Gateway. Because SIIT-DC builds on and closely
resembles <xref target="RFC6145">SIIT</xref>, this section should be
read as a set of additions and changes that are applied to an
implementation already compliant to <xref target="RFC6145">SIIT</xref>.
Each of the following subsections discuss how the requirement relates to
with any corresponding requirements in <xref
target="RFC6145">SIIT</xref>.
</t>
<section title="Compliance with RFC6145 and RFC6052">
<t>
Unless otherwise stated in the following sections, an SIIT-DC
implementation MUST comply fully with <xref target="RFC6145"/>. It
must also implement the algorithmic address mapping defined in <xref
target="RFC6052"/>.
</t>
</section>
<section title="Static Address Mapping Function">
<t>
The implementation MUST allow the operator to configure an arbitrary
number of Static Address Mappings which override the default <xref
target="RFC6052"/> algorithm. It SHOULD be possible to specify a
single bi-directional mapping that will be used in both the
IPv4=>IPv6 and IPv6=>IPv4 directions, but it MAY additionally
(or alternatively) support unidirectional mappings.
</t>
<t>
An example of such a bidirectional Static Address Mapping would be:
</t>
<t>
<list style="symbols">
<t>192.0.2.1 <=> 2001:db8:12:34::1</t>
</list>
</t>
<t>
To accomplish the same using unidirectional mappings, the following
two mappings must instead be configured:
</t>
<t>
<list style="symbols">
<t>192.0.2.1 => 2001:db8:12:34::1</t>
<t>2001:db8:12:34::1 => 192.0.2.1</t>
</list>
</t>
<t>
In both cases, if the SIIT-DC Gateway receives an IPv6 packet that has
the value 2001:db8:12:34::1 in either the source or destination field
of the IPv6 header, it MUST rewrite this field to 192 0.2.1 when
translating to IPv4. Similarly, if the SIIT-DC Gateway receives an
IPv4 packet that has the value 192.0.2.1 as the either the source or
destination field of the IPv4 header, it MUST rewrite this field to
2001:db8:12:34::1 when translating to IPv6. For all IPv4 or IPv6
source or destination field values for which there are no Static
Address Mapping, <xref target="RFC6052"/> compliant mapping MUST be
used instead.
</t>
<t>
Relation to <xref target="RFC6145"/>: The Static Address Mapping is a
novel feature feature that is not discussed in <xref
target="RFC6145"/>. It conflicts with <xref target="RFC6145"/>'s
requirement that all addresses must be translated according to the
<xref target="RFC6052"/> algorithm.
</t>
</section>
<section anchor="feat_incrv6pmtu"
title="Support for Increasing the IPv6 Path MTU">
<t>
The SIIT-DC Gateway MUST provide a configuration function for the
network administrator to adjust the threshold of the minimum IPv6 MTU
to a value that reflects the real value of the minimum IPv6 MTU in the
network (greater than 1280 bytes). This will help reduce the chance of
including the Fragment Header in the packets.
</t>
<t>
Relation to <xref target="RFC6145"/>: This strengthens the
corresponding "MAY" requirement located in <xref
target="RFC6145">Section 4 of RFC6145</xref> to a "MUST".
</t>
</section>
<section anchor="feat_noatomicfrags"
title="Support for Disabling "Atomic Fragments"">
<t>
When the IPv4 sender does not set the DF bit, the SIIT-DC Gateway
SHOULD NOT include an IPv6 Fragment Header in resulting non-fragmented
IPv6 packets. If does, the SIIT-DC Gateway MUST provide a
configuration function that allows the SIIT-DC Gateway not to include
the Fragment Header for the non-fragmented IPv6 packets.
</t>
<t>
Relation to <xref target="RFC6145"/>: This is an update of the
corresponding requirement in <xref target="RFC6145">Section 4 of
RFC6145</xref>. It inverts the recommended default behaviour to not
generate IPv6 Atomic Fragments, and strengthens the "MAY" requirement
for making it possible to disable this behaviour to a "MUST".
</t>
<t>
For the definition of an "Atomic Fragment", see <xref
target="RFC6946"/>.
</t>
</section>
<section anchor="feat_smallv4pmtu"
title="Feature for Handling IPv4 Path MTUs Lower than 1260">
<t>
In order to prevent unnecessary fragments, the implementation SHOULD
support a feature which, if enabled by the operator, changes the
SIIT-DC Gateway's default behaviour accordingly:
</t>
<t>
<list style="symbols">
<t>When translating an ICMPv4 Need To Fragment packet indicating a
Path MTU smaller than or equal to 1260, the MTU field in the
resulting ICMPv6 Packet Too Big is set to 1280.</t>
<t>When translating an IPv6 packet that is smaller or equal to 1280
bytes, the DF flag in the resulting IPv4 packet is cleared, and an
IPv4 Identification value is generated. The SIIT-DC Gateway MUST NOT
create or maintain any state as a result of this.</t>
</list>
</t>
<t>
Relation to <xref target="RFC6145"/>: This is a modified version of
the second approach described in <xref target="RFC6145">Section 6 of
RFC6145</xref>. The modifications are:
</t>
<t>
<list style="numbers">
<t>In the IPv4-to-IPv6 direction, the algorithm only used for ICMPv4
Need To Fragment packets that indicate an MTU value smaller or equal
to 1260. The corresponding value used by <xref target="RFC6145"/> is
smaller than 1280.</t>
<t>In the IPv6-to-IPv4 direction, an SIIT Gateway MUST NOT generate
and maintain any state due to generating IPv4 Identification values.
<xref target="RFC6145"/> RECOMMENDS that this is done.</t>
</list>
</t>
<t>
Also see <xref target="I-D.gont-6man-deprecate-atomfrag-generation"/>,
which seeks to formally update <xref target="RFC6145"/> with the
approach described in this section.
</t>
</section>
<section title="Loop Prevention Mechanism">
<t>
As noted in <xref target="sec_loops"/>, there is a potential for
packets looping through the SIIT-DC function if it receives an IPv4
packet for which there is no Static Address Mapping. It is therefore
RECOMMENDED that the implementation has a mechanism that automatically
prevents this behaviour. One way this could be accomplished would be
to discard any IPv4 packets that would be translated into an IPv6
packet that would be routed straight back into the SIIT-DC function.
</t>
<t>
If such a mechanism isn't provided, the implementation MUST provide a
way to manually filter or null-route the destination addresses that
would otherwise cause loops.
</t>
<t>
Relation to <xref target="RFC6145"/>: This security consideration
applies only when an SIIT-DC Gateway translates a packet in "pure"
<xref target="RFC6145">SIIT</xref> mode (i.e., both address fields are
translated according to <xref target="RFC6052"/>). This consideration
is in other words not specific to SIIT-DC, it is inherited from <xref
target="RFC6145"/>. In spite of this, <xref target="RFC6145"/> does
not describe this consideration or any methods of prevention. The
requirements in this section is therefore novel to SIIT-DC, even
though they apply equally to <xref target="RFC6145"/>.
</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The author would like to thank the following individuals for their
contributions, suggestions, corrections, and criticisms: Fred Baker,
Cameron Byrne, Ross Chandler, Dagfinn Ilmari Mannsaaker, Lars Olafsen,
Stig Sandbeck Mathisen, [YOUR NAME GOES HERE].
</t>
</section>
<section title="Requirements Language">
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This draft makes no request of the IANA. The RFC Editor may remove this
section prior to publication.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<section title="Mistaking the Translation Prefix for a Trusted Network">
<t>
If a Network-Specific Prefix from the provider's own address space is
chosen for the translation prefix, as is recommended, care must be
taken if the translation service is used in front of services that
have application-level ACLs that distinguish between the operator's
own networks and the Internet at large, as the translated IPv4 end
users on the Internet will appear to come from within the provider's
own IPv6 address space. It is therefore important that the translation
prefix is treated the same as the Internet at large, rather than as a
trusted network.
</t>
</section>
<section anchor="sec_loops"
title="Packets Looping Through the SIIT-DC Function">
<t>
If the SIIT-DC Gateway receives an IPv4 packet destined to an address
for which there is no Static Address Mapping, its destination address
will be rewritten according to <xref target="RFC6052"/>, making the
resulting IPv6 packet have a destination address within the
translation prefix, which is likely routed to back to the SIIT-DC
function. This will cause the packet to loop until its Time To Live /
Hop Limit reaches zero, potentially creating a Denial Of Service
vulnerability.
</t>
<t>
To avoid this, it should be ensured that packets sent to IPv4
destinations addresses for which there are no Static Address Mappings,
or whose resulting IPv6 address does not have a more-specific route to
the IPv6 network, are immediately discarded.
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.6052"?>
<?rfc include="reference.RFC.6145"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0959"?>
<?rfc include="reference.RFC.1918"?>
<?rfc include="reference.RFC.2373"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.2616"?>
<?rfc include="reference.RFC.2663"?>
<?rfc include="reference.RFC.2991"?>
<?rfc include="reference.RFC.2993"?>
<?rfc include="reference.RFC.3022"?>
<?rfc include="reference.RFC.3235"?>
<?rfc include="reference.RFC.4213"?>
<?rfc include="reference.RFC.4217"?>
<?rfc include="reference.RFC.6146"?>
<?rfc include="reference.RFC.6147"?>
<?rfc include="reference.RFC.6540"?>
<?rfc include="reference.RFC.6946"?>
<?rfc include="reference.I-D.taylor-v6ops-fragdrop"?>
<?rfc include="reference.I-D.gont-6man-deprecate-atomfrag-generation"?>
<!-- replace the below with
<?rfc include="reference.I-D.anderson-v6ops-siit-dc-2xlat"?> once
the drafts have been uploaded to the IETF web site -->
<reference anchor='I-D.anderson-v6ops-siit-dc-2xlat'>
<front>
<title>SIIT-DC: Dual Translation Mode</title>
<author initials='T' surname='Anderson' fullname='Tore Anderson'>
<organization />
</author>
<date month='September' day='15' year='2014' />
<abstract><t>This document describes an extension of the SIIT-DC
architecture, which allows applications that are incompatible with
SIIT-DC and/or Network Address Translation in general to operate
correctly in an SIIT-DC environment.</t></abstract>
</front>
<seriesInfo name='Internet-Draft'
value='draft-anderson-v6ops-siit-dc-2xlat-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-anderson-v6ops-siit-dc-2xlat-00.txt' />
</reference>
</references>
<section title="Complete SIIT-DC topology example">
<t>
This figure shows a more complete SIIT-DC topology, in order to better
demonstrate the beneficial properties it has. In particular, it tries to
highlight the following:
</t>
<t>
<list style="symbols">
<t>Stateless operation: Any number of SIIT-DC Gateways may be deployed
side-by side, or indeed anywhere in the IPv6 network, as any standard
routing mechanism may be used to direct traffic to them (shown here
with BGP on the IPv4 side and ECMP on the IPv6 side). This in turn
leads to high availability, should one of the SIIT-DC Gateways fail or
become unavailable, those standard routing mechanisms will ensure that
traffic is automatically redirect one of the remaining SIIT-DC
Gateways.</t>
<t>IPv4 address conservation: Even though the to customers in the
example have several hundred servers, most of them are not used for
externally available services, and thus do not require an IPv4
address. The network between the servers and the SIIT-DC Gateways
require no IPv4 addresses, either. Furthermore, the IPv4 addresses
that are used do not have to be assigned to customers in the form of
aggregated blocks or prefixes; which makes it easy to achieve 100%
effective utilisation of the IPv4 service address pools.</t>
<t>Application support: The translation-friendly applications HTTP and
SMTP will work through SIIT-DC without requiring any special
customisation. Furthermore, translation-unfriendly applications such
as FTP will also work if an host agent in present, cf. <xref
target="I-D.anderson-v6ops-siit-dc-2xlat"/>.</t>
<t>Native IPv6 as the foundation: Every server, application, and
network component has access to native and untranslated IPv6
connectivity to each other and to the Internet. Traffic through the
SIIT-DC Gateways will diminish over time as IPv6 is deployed
throughout the Internet. Eventually they may be shut down entirely,
which causes no disruption to the application stacks' ability to
deliver their services over native IPv6.</t>
</list>
</t>
<t>
<figure anchor="fig_topology" align="center">
<preamble>Example data centre topology using SIIT-DC</preamble>
<artwork align="center"><![CDATA[
/--------------------------------\ /---------------\
| IPv4 Internet | | IPv6 Internet |
\-+----------------------------+-/ \--------+------/
| | |
| <----------[BGP]---------> | |
| | |
+---------<192.0.2.0/24>----------+ +---<192.0.2.0/24>---+ |
| | | | |
| SIIT-DC Gateway 1 | | SIIT-DC Gateway 2 | |
| ================= | | ================= | |
| | | | |
| Translation Prefix: | | | |
| 2001:db8:46::/96 | | | |
| | | | |
| Static Address Mappings: | | Exactly the same | |
| 192.0.2.1 <=> 2001:db8:12:34::1 | | configuration as | |
| 192.0.2.2 <=> 2001:db8:12:34::2 | | SIIT-DC Gateway 1 | |
| 192.0.2.3 <=> 2001:db8:fe:dc::1 | | | |
| 192.0.2.4 <=> 2001:db8:12:34::4 | | | |
| [...] | | | |
| | | | |
+--------<2001:db8:46::/96>-------+ +-<2001:db8:46::/96>-+ |
| | |
| <---------[ECMP]---------> | |
| | |
/-----------------+----------------------------+-\ |
| IPv6 data centre network +----------+
\-+-----------------------------------+----------/
| |
| Customer A's server LAN | Customer B's server LAN
| 2001:db8:12:34::/64 | 2001:db8:fe:dc::/64
| |
| |
+-- www ::1 (IPv6+SIIT-DC) +-- www ::1 (IPv6+SIIT-DC)
| |
| +-- file01 ::f:01 (IPv6)
+-- mta ::2 (IPv6+SIIT-DC) | [...]
| +-- file99 ::f:99 (IPv6)
+-- ftp ::3 (IPv6)
| ::4 (SIIT-DC/Host Agent)
|
+-- app01 ::a:01 (IPv6)
| [...]
+- app99 ::a:99 (IPv6)
|
+-- db01 ::d:01 (IPv6)
| [..]
+-- db99 ::d:99 (IPv6)
]]></artwork>
</figure>
</t>
</section>
<section title="Comparison to Other Deployment Approaches">
<t>
There are a number of alternative deployment strategies a data centre
operator may follow. They each have different properties and helps solve
a different set of challenges. This section aims to compare the SIIT-DC
approach with each of the most common ones, by highlighting the benefits
and disadvantages of each.
</t>
<section title="IPv4-only">
<t>
At the time of writing, IPv4-only operation remains the status quo for
most operators. As such, it is well understood and supported. An
operator can reasonably expect everything to work correctly in an
IPv4-only environment.
</t>
<t>
Benefits of IPv4-only operation compared to SIIT-DC include:
</t>
<t>
<list style="symbols">
<t>No translation occurs, the end-to-end principle is intact.</t>
<t>Compatible with all common application protocols.</t>
<t>Compatible with IPv4-only devices.</t>
<t>Compatible with IPv4-only application software, without requiring
a host agent.</t>
</list>
</t>
<t>
Disadvantages of IPv4-only operation compared to SIIT-DC include:
</t>
<t>
<list style="symbols">
<t>Does not provide any form of IPv6 connectivity.</t>
<t>Does not alleviate IPv4 address scarcity.</t>
</list>
</t>
</section>
<section title="IPv4-only + NAPT44">
<t>
An operator who would otherwise chose a traditional IPv4-only
approach, but cannot due to having insufficient public IPv4 addresses
available, could chose to deploy using a combination of <xref
target="RFC1918">private IPv4 addresses</xref> and <xref
target="RFC3022">NAPT44</xref> devices which will translate between a
smaller number of public IPv4 addresses and the private addresses
assigned to the servers that provide public services to the Internet.
</t>
<t>
Benefits of IPv4-only + NAPT44 operation compared to SIIT-DC include:
</t>
<t>
<list style="symbols">
<t>Compatible with IPv4-only devices.</t>
<t>Compatible with IPv4-only application software, without requiring
a host agent.</t>
</list>
</t>
<t>
Disadvantages of IPv4-only + NAPT44 operation compared to SIIT-DC
include:
</t>
<t>
<list style="symbols">
<t>Does not provide any form of IPv6 availability.</t>
<t>Requires network devices that track all flow state, which may
create a performance bottleneck and be an easy target for Denial of
Service attacks.</t>
<t>Limits routing flexibility (prevents closest exit routing), as
outbound traffic must pass across the same NAPT44 device that
handled the inbound traffic.</t>
<t>Limited potential for horizontal scaling, as packets cannot be
load-balanced across multiple NAT devices.</t>
<t>
Depending on whether or not the NAPT44 device rewrites source
addresses in order to attract the return traffic to itself:
</t>
<t>
<list style="symbols">
<t>Obscures the true source address of the user from the
server/application, preventing it from e.g. performing
geo-location lookups, or:</t>
<t>Requires an IPv4 default route to be pointed to the NAPT44
device, also attracting native traffic that does not need to
undergo translation.</t>
</list>
</t>
</list>
</t>
<t>
In addition, application compatibility is a consideration with both
NAPT44 and SIIT-DC, but the exact nature depends from application to
application, so it is hard to objectively quantify if there is a clear
advantage to either approach here. Some translation-unfriendly
application protocols may work without host modifications through the
use of Application Layer Gateway support in the NAPT44 device (e.g.,
<xref target="RFC0959">FTP</xref>), or in the SIIT-DC architecture
when a host agent is being used <xref
target="I-D.anderson-v6ops-siit-dc-2xlat"/>. Other application
protocols might not work with NAPT44 at all, but will work in the
SIIT-DC if a host agent is being used (e.g., <xref
target="RFC4217">FTP/TLS</xref>).
</t>
<t>
In summary, the most accurate statement would be to say that a NAPT44
architecture is more compatible with translation-unfriendly protocols
than plain SIIT-DC, while SIIT-DC is more compatible than NAPT44 if a
host agent is used.
</t>
<t>
For a more complete discussion of potential issues with running
NAPT44, see <xref target="RFC2993">Architectural Implications of
NAT</xref>.
</t>
</section>
<section title="Dual Stack">
<t>
<xref target="RFC4213">Dual Stack</xref> could be used both with or
without NAPT44 to handle IPv4. In general, the benefits and
disadvantages are equal to the corresponding IPv4-only option, except
for the fact that Dual Stack does provides IPv6 connectivity.
Therefore, his section only lists the benefits and disadvantages which
are unique to a Dual Stack environment.
</t>
<t>
Benefits of Dual Stack operation compared to SIIT-DC include:
</t>
<t>
<list style="symbols">
<t>No translation occurring, the end-to-end principle is intact
(assuming NAPT44 isn't used).</t>
<t>Compatible with all common application protocols (assuming NAPT44
isn't used).</t>
<t>Compatible with IPv4-only devices.</t>
<t>Compatible with IPv4-only application software, without requiring
a host agent.</t>
</list>
</t>
<t>
Disadvantages of Dual Stack operation compared to SIIT-DC include:
</t>
<t>
<list style="symbols">
<t>Does not alleviate IPv4 address scarcity (assuming NAPT44 isn't
used).</t>
<t>Increases the complexity of the infrastructure, as many things
must done twice (once for IPv4 and once for IPv6). Examples of
things that must be duplicated in this manner under Dual Stack:
Firewall rules/ACLs, IGP topology, monitoring, troubleshooting.</t>
<t>Encourages software developers, systems administrators, etc. to
build architectures that cannot operate correctly without IPv4. This
in turn makes it difficult to make use of Dual Stack as a short term
transitional stage, rather than a near-permanent end state.</t>
<t>Increases the amount of things that can encounter failures, and
increases the time required to locate and fix such failures. This
reduces reliability.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
<!-- Change Log
v00 2012-10-12 tore Initial version
-->
<!-- vim: syntax=xml tw=78 ai fo=2 et:
-->
| PAFTECH AB 2003-2026 | 2026-04-24 00:57:44 |