One document matched: draft-anderson-v6ops-siit-eam-03.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-03"
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>
<!-- Embedding the postal code directly in the <city> element
instead of using <code> in necessary to get correct Norwegian
syntax. For more information, see:
http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/280 -->
<city>0485 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="2015" />
<area>General</area>
<workgroup>IPv6 Operations</workgroup>
<abstract>
<t>
This document extends the Stateless IP/ICMP Translation Algorithm (SIIT)
with an Explicit Address Mapping (EAM) algorithm, and formally updates
RFC 6145. The EAM 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_spec"/>.</t>
<t hangText="EAMT"><vspace/>The Explicit Address Mapping Table, as
specified in <xref target="eamt_spec"/>.</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="eamt_spec" 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_spec" 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. <xref target="fig_example_eamt"/>
illustrates an EAMT containing examples of valid EAMs.
</t>
<t>
<figure anchor="fig_example_eamt" align="center">
<preamble>Example EAMT</preamble>
<artwork align="center"><![CDATA[
+---+----------------+----------------------+
| # | IPv4 Prefix | IPv6 Prefix |
+---+----------------+----------------------+
| 1 | 192.0.2.1 | 2001:db8:aaaa:: |
| 2 | 192.0.2.2/32 | 2001:db8:bbbb::b/128 |
| 3 | 192.0.2.16/28 | 2001:db8:cccc::/124 |
| 4 | 192.0.2.128/26 | 2001:db8:dddd::/64 |
| 5 | 192.0.2.192/31 | 64:ff9b::/127 |
+---+----------------+----------------------+
]]></artwork>
</figure>
</t>
<t>
An EAM's IPv4 Prefix value MUST have an identical or smaller number of
suffix bits than its corresponding IPv6 Prefix value.
</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>
<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) according to <xref target="eam_xlat"/>.
</t>
</section>
<section anchor="eam_xlat" title="IP Address Translation Procedure">
<t>
This section describes step-by-step how an SIIT implementation
translates addresses between IPv4 and IPv6. Only the outcome of the
algorithm described should be considered normative, that is, an SIIT
implementation MAY implement the exact procedure differently than what
is described here, but the outcome of the algorithm MUST be the same.
</t>
<t>
For concrete examples of IP addresses translations, refer to <xref
target="eam_examples"/>.
</t>
<section anchor="eam_xlat_v4v6"
title="Address Translation Steps: IPv4 to IPv6">
<t>
<list style="numbers">
<t>The EAMT is searched for an EAM entry containing an IPv4 Prefix
identical to that of the IPv4 address being translated. The IPv4
Prefix and IPv6 Prefix values of the EAM entry found is from now
on referred to as EAM4 and EAM6, respectively.</t>
<t>If no matching EAM entry is found, the EAM algorithm is
aborted. The SIIT implementation MUST proceed to translate the
address in accordance with <xref target="RFC6145"/> (and its
updates).</t>
<t>The prefix bits of EAM4 are removed from IPv4 address being
translated. The remaining suffix bits from the IPv4 address being
translated are stored in a temporary buffer.</t>
<t>The prefix bits of EAM6 are prepended to the temporary
buffer.</t>
<t>If the temporary buffer at this point does not contain a
128-bit value, it is padded with trailing zeroes so that it
reaches a length of 128 bits.</t>
<t>The contents of the temporary buffer is the translated IPv6
address.</t>
</list>
</t>
</section>
<section anchor="eam_xlat_v6v4"
title="Address Translation Steps: IPv6 to IPv4">
<t>
<list style="numbers">
<t>The EAMT is searched for an EAM entry containing an IPv6 Prefix
identical to that of the IPv6 address being translated. The IPv4
Prefix and IPv6 Prefix values of the EAM entry found is from now
on referred to as EAM4 and EAM6, respectively.</t>
<t>If no matching EAM entry is found, the EAM algorithm is
aborted. The SIIT implementation MUST proceed to translate the
address in accordance with <xref target="RFC6145"/> (and its
updates).</t>
<t>The prefix bits of EAM6 are removed from IPv6 address being
translated. The remaining suffix bits from the IPv6 address being
translated are stored in a temporary buffer.</t>
<t>The prefix bits of EAM4 are prepended to the temporary
buffer.</t>
<t>If the temporary buffer at this point does not contain a 32-bit
value, any trailing bits are discarded so that the buffer is
reduced to a length of 32 bits.</t>
<t>The contents of the temporary buffer is the translated IPv4
address.</t>
</list>
</t>
</section>
</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.6219"?>
<?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 at the time of
writing leverage SIIT with the EAM algorithm.
</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 conversely, 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_ivi" title="IVI">
<t>
<xref target="RFC6219">IVI</xref> describes a stateless translation
model that embeds IPv4 addresses in a 40-bit translation prefix where
bits 33-40 are required to be 1. The embedded IPv4 address is located
in bits 41-72 of the IPv6 address. Bits 73-128 are required to be 0.
</t>
<t>
The location of the eight least significant IPv4 address bits makes
the IVI address mapping differ from <xref target="RFC6052"/>.
</t>
<t>
<figure anchor="fig_eamt_ivi" align="center">
<preamble>Example EAMT for IVI</preamble>
<artwork align="center"><![CDATA[
+---+-------------+--------------------+
| # | IPv4 Prefix | IPv6 Prefix |
+---+-------------+--------------------+
| 1 | 0.0.0.0/0 | 2001:db8:ff00::/40 |
+---+-------------+--------------------+
]]></artwork>
</figure>
</t>
<t>
In this particular use case, all addresses are translated according to
the EAM algorithm. In other words, <xref target="RFC6052"/> mapping is
not used at all.
</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 conversely, 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>
<section anchor="eam_examples" title="Example IP Address Translations">
<t>
<xref target="fig_example_eam_xlat"/> demonstrates how a set of example
IP addresses are translated given the example EAMT in <xref
target="fig_example_eamt"/>. Implementors may use the examples given to
develop test cases to validate correct operation. Note that the address
translations are bidirectional, so a single row in the table describes
two address translations: IPv4 to IPv6, and IPv6 to IPv4.
</t>
<t>
It is also assumed that the <xref target="RFC6052"/> translation prefix
is configured to be 64:ff9b::/96.
</t>
<t>
<figure anchor="fig_example_eam_xlat" align="center">
<preamble>Example IP Address Translations</preamble>
<artwork align="center"><![CDATA[
+--------------+------------------------+-----------------------+
| IPv4 Address | IPv6 Address | Comment |
+--------------+------------------------+-----------------------+
| 192.0.2.1 | 2001:db8:aaaa:: | According to EAM #1 |
| 192.0.2.2 | 2001:db8:bbbb::b | According to EAM #2 |
| 192.0.2.16 | 2001:db8:cccc:: | According to EAM #3 |
| 192.0.2.24 | 2001:db8:cccc::8 | According to EAM #3 |
| 192.0.2.31 | 2001:db8:cccc::f | According to EAM #3 |
| 192.0.2.128 | 2001:db8:dddd:: | According to EAM #4 |
| 192.0.2.152 | 2001:db8:dddd:0:6000:: | According to EAM #4 |
| 192.0.2.183 | 2001:db8:dddd:0:dc00:: | According to EAM #4 |
| 192.0.2.191 | 2001:db8:dddd:0:fc00:: | According to EAM #4 |
| 192.0.2.193 | 64:ff9b::1 | According to EAM #5 |
| 192.0.2.200 | 64:ff9b::c000:2c8 | According to RFC 6052 |
+--------------+------------------------+-----------------------+
]]></artwork>
</figure>
</t>
</section>
</back>
</rfc>
<!-- vim: syntax=xml tw=78 ai fo=2 et:
-->
| PAFTECH AB 2003-2026 | 2026-04-24 08:17:06 |