One document matched: draft-anderson-v6ops-siit-eam-01.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-eam-01"
ipr="trust200902" updates="6145">
<front>
<title abbrev="SIIT-EAM">Explicit Address Mappings for Stateless IP/ICMP
Translation</title>
<author fullname="Tore Anderson" initials="T." surname="Anderson">
<organization>Redpill Linpro</organization>
<address>
<postal>
<street>Vitaminveien 1A</street>
<code>0485</code>
<city>Oslo</city>
<country>Norway</country>
</postal>
<phone>+47 959 31 212</phone>
<email>tore@redpill-linpro.com</email>
<uri>http://www.redpill-linpro.com</uri>
</address>
</author>
<date year="2014" />
<area>General</area>
<workgroup>IPv6 Operations</workgroup>
<abstract>
<t>
This document extends the Stateless IP/ICMP Translation Algorithm (SIIT)
with an Explicit Address Mapping algorithm. This algorithm facilitates
stateless IP/ICMP translation between arbitrary (non-IPv4-translatable)
IPv6 endpoints and IPv4.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The <xref target="RFC6145">Stateless IP/ICMP Translation Algorithm
(SIIT)</xref> specifies that when translating IPv4 addresses to IPv6 and
vice versa, all addresses must be translated using the algorithm
specified in <xref target="RFC6052"/>. This document specifies an
alternative to the <xref target="RFC6052"/> algorithm, where IP
addresses are translated according to a table of Explicit Address
Mappings configured on the stateless translator. This removes the
previous constraint that IPv6 nodes that communicate with IPv4 nodes
through SIIT must be configured with IPv4-translatable IPv6 addresses.
</t>
<t>
The Explicit Address Mapping Table does not replace <xref
target="RFC6052"/>. For most use cases, it is expected that both
algorithms are used in concert. The Explicit Address Mapping algorithm
is used only when a mapping matching the address to be translated
exists. If no matching mapping exists, the <xref target="RFC6052"/>
algorithm will be used instead. Thus, when translating an individual IP
packet, an SIIT implementation might translate one of the two IP address
fields according to an EAM, while the other IP address field is
translated according to <xref target="RFC6052"/>.
</t>
<section anchor="terminology" title="Terminology">
<t>
This document makes use of the following terms:
</t>
<t>
<list style="hanging">
<t hangText="EAM"><vspace/>An Explicit Address Mapping, as specified
in <xref target="eam_def"/>.</t>
<t hangText="EAMT"><vspace/>The Explicit Address Mapping Table, as
specified in <xref target="eam_def"/>.</t>
<t hangText="SIIT"><vspace/>The Stateless IP/ICMP Translation
algorithm, as specified in <xref target="RFC6145"/>.</t>
<t hangText="IPv4-converted IPv6 addresses"><vspace/>As defined in
Section 1.3 of <xref target="RFC6052"/>.</t>
<t hangText="IPv4-translatable IPv6 addresses"><vspace/>As defined in
Section 1.3 of <xref target="RFC6052"/>.</t>
</list>
</t>
<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>
<section anchor="problemstatement" title="Problem Statement">
<t>
Section 3.2.1 of <xref target="RFC6144"/> notes that "stateless
translation mechanisms typically put constraints on what IPv6 addresses
can be assigned to IPv6 nodes that want to communicate with IPv4
destinations using an algorithmic mapping". In practice, this means that
the IPv6 nodes must be configured with IPv4-translatable IPv6 addresses.
For the reasons discussed below, some environments may find that the use
of IPv4-translatable IPv6 addresses is not desired or even possible.
</t>
<t>
<list style="hanging">
<t hangText="Limited availability:"><vspace/>The number of
IPv4-translatable IPv6 addresses available to an operator is equal to
the number of IPv4 addresses he assigns to the SIIT function. IPv4
addresses are scarce, and as a result an operator might not have enough
IPv4-translatable IPv6 addresses to number his entire IPv6
infrastructure.</t>
<t hangText="Restricted format:"><vspace/>IPv4-translatable IPv6
addresses must conform to the format specified in Section 2.2 of <xref
target="RFC6052"/>. This format is not compatible with other common
IPv6 address formats, such as the EUI-64 based IPv6 address format used
by <xref target="RFC4862">IPv6 Stateless Address
Autoconfiguration</xref>.</t>
</list>
</t>
<t>
An operator could overcome the above two problems by building an IPv6
network using regular (non-IPv4-translatable) IPv6 addresses, and assign
IPv4-translatable IPv6 addresses as secondary addresses on the nodes
that want to communicate with IPv4 nodes through SIIT only. However,
doing so may result in a new set of undesired properties:
</t>
<t>
<list style="hanging">
<t hangText="Routing complexity:"><vspace/>The IPv4-translatable IPv6
addresses must be routed throughout the IPv6 network separately from
the primary (non-IPv4-translatable) IPv6 addresses used by the nodes.
It might be impossible to aggregate these routes, as two adjacent
IPv4-translatable IPv6 addresses might not be assigned to two adjacent
IPv6 nodes. As a result, in order to support SIIT, the IPv6 network
might need to carry a large number of extraneous routes. These routes
must be separately injected into the IPv6 routing topology somehow. Any
intermediate devices in the IPv6 network such as a firewall might
require special configuration in order to treat the IPv4-translatable
IPv6 address the same as the primary IPv6 address, for example by
requiring that any ACL entries involving the primary IPv6 address of a
node must be duplicated.</t>
<t hangText="Operational complexity:"><vspace/>The IPv4-translatable
IPv6 addresses must not only be assigned to the IPv6 nodes
participating in SIIT; all applications and services on those nodes
must also be configured to use them. For example, if the IPv6 node is a
load balancer, it might require a separate Virtual Server definition
using the IPv4-translatable IPv6 address in addition to one using the
service's primary IPv6 address. A web server might require specific
configuration to listen for connections on both the IPv4-translatable
and the primary IPv6 address. A High-Availability cluster service must
be set up to fail over both addresses between cluster nodes, and
depending on how the IPv6 network learns the location of the
IPv4-translatable IPv6 address, the fail-over mechanism used for the
two addresses might be completely different. Service monitoring must be
done for both the IPv4-translatable and the primary IPv6 address, and
any trouble-shooting procedures must be extended to involve both
addresses.</t>
</list>
</t>
<t>
In short, the use of IPv4-translatable IPv6 addresses in parallel with
regular IPv6 addresses is in many ways analogous to the use of <xref
target="RFC4213">Dual Stack</xref>. While no actual IPv4 packets are
used, the IPv4-translatable IPv6 addresses creates a secondary "stack"
in the infrastructure that must be treated and operated separately from
the primary one. This increases the complexity of the overall
infrastructure, in turn increasing operational overhead, and reducing
reliability. An operator who for such reasons finds the use Dual Stack
unappealing, might feel the same way about using SIIT with
IPv4-translatable IPv6 addresses.
</t>
</section>
<section anchor="eam_def" title="Explicit Address Mapping Algorithm">
<t>
This normative section defines the EAM algorithm. SIIT implementations
are REQUIRED to support the specifications herein.
</t>
<section anchor="eam_tbl" title="Explicit Address Mapping Table">
<t>
An SIIT implementation MUST include an Explicit Address Mapping Table
(EAMT). By default, the EAMT SHOULD be empty. The operator MUST be
able to populate the EAMT using the implementation's normal
configuration interfaces. The implementation MAY additionally support
other ways of populating the EAMT.
</t>
<t>
The EAMT consists of the following columns:
</t>
<t>
<list>
<t>IPv4 Prefix</t>
<t>IPv6 Prefix</t>
</list>
</t>
<t>
SIIT implementations MAY include other columns in order to support
proprietary extensions to the EAM algorithm.
</t>
<t>
Throughout this document, figures representing the EAMT contain an
Index column using the pound sign as the header. This column is not a
required part of this specification; it is included only as a
convenience to the reader.
</t>
</section>
<section anchor="eam_types" title="Explicit Address Mapping Specification">
<t>
An EAM consists of an IPv4 Prefix and an IPv6 Prefix. The prefix
length MAY be omitted, in which case the implementation MUST assume it
to be 32 for IPv4 and 128 for IPv6.
</t>
<t>
<figure anchor="fig_eam_table" align="center">
<preamble>Example Explicit Address Mapping Table</preamble>
<artwork align="center"><![CDATA[
+---+--------------+-----------------+
| # | IPv4 Prefix | IPv6 Prefix |
+---+--------------+-----------------+
| 1 | 192.0.2.1 | 2001:db8:: |
| 2 | 192.0.2.2/32 | 2001:db8::2/128 |
| 3 | 192.0.2.3 | 2001:db8::3 |
| 4 | 192.0.2.4/30 | 2001:db8::8/126 |
+---+--------------+-----------------+
]]></artwork>
</figure>
</t>
<t>
When translating a packet between IPv4 and IPv6, an SIIT
implementation MUST individually translate each IP address it
encounters in the packet's IP headers (including any IP headers
contained within ICMP errors) as follows:
</t>
<t>
<list style="symbols">
<t>When translating an IPv4 address to IPv6, the SIIT implementation
MUST first look up a matching prefix for the IPv4 address to be
translated in the IPv4 Prefix column of the EAMT. If a matching EAM
entry is found, the address MUST be translated to IPv6 by
substituting its IPv4 Prefix value for the corresponding IPv6 Prefix
from the EAM entry.</t>
<t>When translating an IPv6 address to IPv4, the SIIT implementation
MUST first look up a matching prefix for the IPv6 address to be
translated in the IPv6 Prefix column of the EAMT. If a matching EAM
entry is found, the address MUST be translated to IPv4 by
substituting its IPv6 Prefix value for the corresponding IPv4 Prefix
from the EAM entry.</t>
<t>If no matching EAM is found, the SIIT implementation MUST proceed
to translate the address in accordance with <xref target="RFC6145"/>
(and its updates).</t>
</list>
</t>
<t>
An EAM's IPv4 Prefix and IPv6 Prefix MUST have identical suffix
lengths. Any suffix bits MUST be kept intact during translation.
</t>
<t>
Overlapping EAMs SHOULD be considered an error, and attempts to insert
them into the EAMT SHOULD be blocked. The behaviour of an SIIT
implementation when overlapping EAMs are present in the EAMT is left
undefined.
</t>
</section>
</section>
<section title="Lack of Checksum Neutrality">
<t>
When one or both of the address fields in an IP/ICMP packet are
translated according to EAM, the translation can not be relied upon to
be checksum neutral, even if the well-known prefix 64:ff9b::/96 is used.
This consideration is discussed in more detail in Section 4.1 of <xref
target="RFC6052"/>.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
The EAM algorithm does not introduce any new security issues beyond
those that are already discussed in Section 7 of <xref
target="RFC6145"/>.
</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="acks" title="Acknowledgements">
<t>
This document was conceived due to comments made by Dave Thaler in the
v6ops session at IETF 91 as well as e-mail discussions between Fred
Baker and the author.
</t>
<t>
Valuable reviews, suggestions, and other feedback was given by Cameron
Byrne, Brian E Carpenter, Alberto Leiva, and Andrew Yourtchenko.
</t>
</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.4213"?>
<?rfc include="reference.RFC.4862"?>
<?rfc include="reference.RFC.6144"?>
<?rfc include="reference.RFC.6877"?>
<?rfc include="reference.RFC.7335"?>
<?rfc include="reference.I-D.anderson-v6ops-siit-dc"?>
</references>
<section anchor="usecases" title="Use Cases">
<t>
The following subsections lists some use cases that leverage SIIT with
the EAM algorithm at the time of writing.
</t>
<section anchor="usecase_464xlat" title="464XLAT">
<t>
When the CLAT component in the <xref target="RFC6877">464XLAT</xref>
architecture does not have a dedicated IPv6 prefix assigned, it may
instead use "one interface IPv6 address that is claimed by the CLAT".
This IPv6 address might not be IPv4-translatable. If this is the case,
the CLAT essentially implements the EAM algorithm using an EAMT as
follows (assuming the CLAT's IPv4 address is picked from the <xref
target="RFC7335">IPv4 Service Continuity Prefix</xref>):
</t>
<t>
<figure anchor="fig_eamt_464xlat" align="center">
<preamble>Example EAMT for an 464XLAT CLAT</preamble>
<artwork align="center"><![CDATA[
+---+--------------+-------------------------------+
| # | IPv4 Prefix | IPv6 Prefix |
+---+--------------+-------------------------------+
| 1 | 192.0.0.1/32 | CLAT_claimed_IPv6_address/128 |
+---+--------------+-------------------------------+
]]></artwork>
</figure>
</t>
<t>
In this particular use case, the EAM algorithm is used to translate
IPv6 destination addresses to IPv4, and conversively, IPv4 source
addresses to IPv6. Other addresses are translated using <xref
target="RFC6052"/>. Note that this is the exact opposite of the <xref
target="usecase_siit_dc">SIIT-DC use case</xref>.
</t>
</section>
<section anchor="usecase_siit_dc" title="SIIT-DC">
<t>
<xref target="I-D.anderson-v6ops-siit-dc">SIIT-DC</xref> describes the
use of SIIT to facilitate connectivity from the IPv4 Internet to
services hosted in an IPv6-only data centre. In order to avoid the
constraints relating to the use of IPv4-translatable IPv6 addresses
discussed in <xref target="problemstatement"/> the stateless IPv4/IPv6
translators are provisioned with an EAMT containing one entry per
IPv6-only service that are to be made available from the IPv4
Internet, for example (assuming 2001:db8:aaaa::1 and 2001:db8:bbbb::1
are assigned to load balancers or servers that provides the IPv6-only
services in question):
</t>
<t>
<figure anchor="fig_eamt_siit_dc" align="center">
<preamble>Example EAMT for SIIT-DC</preamble>
<artwork align="center"><![CDATA[
+---+--------------+----------------------+
| # | IPv4 Prefix | IPv6 Prefix |
+---+--------------+----------------------+
| 1 | 192.0.2.1/32 | 2001:db8:aaaa::1/128 |
| 2 | 192.0.2.2/32 | 2001:db8:bbbb::1/128 |
+---+--------------+----------------------+
]]></artwork>
</figure>
</t>
<t>
In this particular use case, the EAM algorithm is used to translate
IPv4 destination addresses to IPv6, and conversively, IPv6 source
addresses to IPv4. Other addresses are translated using <xref
target="RFC6052"/>. Note that this is the exact opposite of the <xref
target="usecase_464xlat">464XLAT use case</xref>.
</t>
</section>
</section>
</back>
</rfc>
<!-- vim: syntax=xml tw=78 ai fo=2 et:
-->
| PAFTECH AB 2003-2026 | 2026-04-24 08:16:51 |