One document matched: draft-anderson-v6ops-siit-eam-01.txt
Differences from draft-anderson-v6ops-siit-eam-00.txt
IPv6 Operations T. Anderson
Internet-Draft Redpill Linpro
Updates: 6145 (if approved) December 04, 2014
Intended status: Standards Track
Expires: June 07, 2015
Explicit Address Mappings for Stateless IP/ICMP Translation
draft-anderson-v6ops-siit-eam-01
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 07, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Anderson Expires June 07, 2015 [Page 1]
Internet-Draft SIIT-EAM December 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Explicit Address Mapping Algorithm . . . . . . . . . . . . . 4
3.1. Explicit Address Mapping Table . . . . . . . . . . . . . 5
3.2. Explicit Address Mapping Specification . . . . . . . . . 5
4. Lack of Checksum Neutrality . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 7
A.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 7
A.2. SIIT-DC . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145]
specifies that when translating IPv4 addresses to IPv6 and vice
versa, all addresses must be translated using the algorithm specified
in [RFC6052]. This document specifies an alternative to the
[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.
The Explicit Address Mapping Table does not replace [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 [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
[RFC6052].
1.1. Terminology
This document makes use of the following terms:
EAM
An Explicit Address Mapping, as specified in Section 3.
Anderson Expires June 07, 2015 [Page 2]
Internet-Draft SIIT-EAM December 2014
EAMT
The Explicit Address Mapping Table, as specified in Section 3.
SIIT
The Stateless IP/ICMP Translation algorithm, as specified in
[RFC6145].
IPv4-converted IPv6 addresses
As defined in Section 1.3 of [RFC6052].
IPv4-translatable IPv6 addresses
As defined in Section 1.3 of [RFC6052].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Problem Statement
Section 3.2.1 of [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.
Limited availability:
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.
Restricted format:
IPv4-translatable IPv6 addresses must conform to the format
specified in Section 2.2 of [RFC6052]. This format is not
compatible with other common IPv6 address formats, such as the
EUI-64 based IPv6 address format used by IPv6 Stateless Address
Autoconfiguration [RFC4862].
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:
Anderson Expires June 07, 2015 [Page 3]
Internet-Draft SIIT-EAM December 2014
Routing complexity:
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.
Operational complexity:
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.
In short, the use of IPv4-translatable IPv6 addresses in parallel
with regular IPv6 addresses is in many ways analogous to the use of
Dual Stack [RFC4213]. 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.
3. Explicit Address Mapping Algorithm
This normative section defines the EAM algorithm. SIIT
implementations are REQUIRED to support the specifications herein.
Anderson Expires June 07, 2015 [Page 4]
Internet-Draft SIIT-EAM December 2014
3.1. Explicit Address Mapping Table
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.
The EAMT consists of the following columns:
IPv4 Prefix
IPv6 Prefix
SIIT implementations MAY include other columns in order to support
proprietary extensions to the EAM algorithm.
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.
3.2. Explicit Address Mapping Specification
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.
Example Explicit Address Mapping Table
+---+--------------+-----------------+
| # | 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 |
+---+--------------+-----------------+
Figure 1
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:
o When translating an IPv4 address to IPv6, the SIIT implementation
MUST first look up a matching prefix for the IPv4 address to be
Anderson Expires June 07, 2015 [Page 5]
Internet-Draft SIIT-EAM December 2014
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.
o 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.
o If no matching EAM is found, the SIIT implementation MUST proceed
to translate the address in accordance with [RFC6145] (and its
updates).
An EAM's IPv4 Prefix and IPv6 Prefix MUST have identical suffix
lengths. Any suffix bits MUST be kept intact during translation.
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.
4. Lack of Checksum Neutrality
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 [RFC6052].
5. Security Considerations
The EAM algorithm does not introduce any new security issues beyond
those that are already discussed in Section 7 of [RFC6145].
6. IANA Considerations
This draft makes no request of the IANA. The RFC Editor may remove
this section prior to publication.
7. Acknowledgements
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.
Anderson Expires June 07, 2015 [Page 6]
Internet-Draft SIIT-EAM December 2014
Valuable reviews, suggestions, and other feedback was given by
Cameron Byrne, Brian E Carpenter, Alberto Leiva, and Andrew
Yourtchenko.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
8.2. Informative References
[I-D.anderson-v6ops-siit-dc]
tore, t., "SIIT-DC: Stateless IP/ICMP Translation for IPv6
Data Centre Environments", draft-anderson-v6ops-siit-dc-01
(work in progress), October 2014.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC
6877, April 2013.
[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335,
August 2014.
Appendix A. Use Cases
The following subsections lists some use cases that leverage SIIT
with the EAM algorithm at the time of writing.
A.1. 464XLAT
Anderson Expires June 07, 2015 [Page 7]
Internet-Draft SIIT-EAM December 2014
When the CLAT component in the 464XLAT [RFC6877] 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 IPv4
Service Continuity Prefix [RFC7335]):
Example EAMT for an 464XLAT CLAT
+---+--------------+-------------------------------+
| # | IPv4 Prefix | IPv6 Prefix |
+---+--------------+-------------------------------+
| 1 | 192.0.0.1/32 | CLAT_claimed_IPv6_address/128 |
+---+--------------+-------------------------------+
Figure 2
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 [RFC6052].
Note that this is the exact opposite of the SIIT-DC use case
(Appendix A.2).
A.2. SIIT-DC
SIIT-DC [I-D.anderson-v6ops-siit-dc] 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 Section 2
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):
Example EAMT for SIIT-DC
+---+--------------+----------------------+
| # | 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 |
+---+--------------+----------------------+
Figure 3
Anderson Expires June 07, 2015 [Page 8]
Internet-Draft SIIT-EAM December 2014
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 [RFC6052].
Note that this is the exact opposite of the 464XLAT use case
(Appendix A.1).
Author's Address
Tore Anderson
Redpill Linpro
Vitaminveien 1A
Oslo 0485
Norway
Phone: +47 959 31 212
Email: tore@redpill-linpro.com
URI: http://www.redpill-linpro.com
Anderson Expires June 07, 2015 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 06:50:56 |