Internet DRAFT - draft-anderson-v6ops-siit-dc-2xlat
draft-anderson-v6ops-siit-dc-2xlat
IPv6 Operations T. Anderson
Internet-Draft Redpill Linpro
Intended status: Standards Track September 15, 2014
Expires: March 19, 2015
SIIT-DC: Dual Translation Mode
draft-anderson-v6ops-siit-dc-2xlat-00
Abstract
This document describes an extension of the SIIT-DC
[I-D.anderson-v6ops-siit-dc] architecture, which allows applications
that are incompatible with IPv6, SIIT-DC and/or Network Address
Translation in general to operate correctly in an SIIT-DC
environment. This is accomplished by introducing a new component
called a SIIT-DC Host Agent, which reverses the translations made by
an SIIT-DC Gateway. The application is thus provided with seemingly
native IPv4 connectivity.
The reader is expected to be familiar with the SIIT-DC architecture
described in [I-D.anderson-v6ops-siit-dc].
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 March 19, 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
Anderson Expires March 19, 2015 [Page 1]
Internet-Draft SIIT-DC-2XLAT September 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SIIT-DC Host Agent Specification . . . . . . . . . . . . . . 4
4. Architectural Overview . . . . . . . . . . . . . . . . . . . 4
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 6
5.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 6
5.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9.1. Address Spoofing . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
SIIT-DC [I-D.anderson-v6ops-siit-dc] describes an architecture where
IPv4-only users can access IPv6-only services through a stateless
translation gateway. However, this only works for applications that
are compatible with Network Address Translation (NAT), due to the
fact that the SIIT-DC Gateway will rewrite the addresses in the IP
header as part of the translation process. SIIT-DC will also fail to
work correctly for applications that make use of legacy IPv4-only
socket calls.
This document remedies this problem by defining an extension to SIIT-
DC. Translations performed by the SIIT-DC Gateway will also be done
in reverse by an SIIT-DC Host Agent running on the server. The
resulting IPv4 packets are then passed to the application. This way,
the application will be able to use legacy IPv4-only socket calls and
/or include references to its own IPv4 address in the application
payload, while maintaining correct operation.
The approach is heavily inspired by and very similar to 464XLAT
[RFC6877]. The SIIT-DC Host Agent described in this document is
almost identical to the CLAT component in 464XLAT, except for the
Anderson Expires March 19, 2015 [Page 2]
Internet-Draft SIIT-DC-2XLAT September 2014
fact that it will be located on a server, rather than on the
customer-side node. Furthermore, an SIIT-DC Host Agent uses
statically configured public IP addresses, whereas a 464XLAT CLAT
uses a dynamic IPv6 address and a private IPv4 address. The SIIT-DC
Gateway described in [I-D.anderson-v6ops-siit-dc] is used instead of
the PLAT described by 464XLAT.
2. Terminology
This document makes use of the following terms:
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.
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 communicate with this address
through the SIIT-DC Gateway and via an IPv4 Service Address.
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 performing
[I-D.anderson-v6ops-siit-dc] translation on packets passing
through it. See Section 3.
SIIT-DC Gateway A device or a logical function that translates
between IPv4 and IPv6 in accordance with
[I-D.anderson-v6ops-siit-dc].
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 adddress fields in the translated
packet's IP header according to any matching Static Address
Mapping.
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 [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.
Anderson Expires March 19, 2015 [Page 3]
Internet-Draft SIIT-DC-2XLAT September 2014
3. SIIT-DC Host Agent Specification
The SIIT-DC Host Agent runs on the servers hosting application which
do not work correctly with the SIIT-DC architecture as specified by
[I-D.anderson-v6ops-siit-dc]. Its task is the performing the exact
same packet translation as the SIIT-DC Gateway, only in reverse. It
therefore shares the same implementation requirements as the SIIT-DC
Gateway defined in Section 4 of [I-D.anderson-v6ops-siit-dc], with
one exception: The SIIT-DC Host Agent is not required to support
configuring an arbitrary number of Static Address Mappings, but it
must support at least one.
The SIIT-DC Host Agent must be configured with a Static Address
Mapping that corresponds exactly with the same mapping found on the
SIIT-DC Gateway. The IPv4 address of the Static Address Mapping
(i.e., the IPv4 Service Address) must be configured on a virtual
network interface which applications running on the server can bind
to, and the server is expected to install a default IPv4 route
poining to this virtual IPv4 interface. The IPv6 address of the
Static Address Mapping must be a secondary address that is routed to
the server by the IPv6 network. The server must forward all packets
it receives destined for this IPv6 address to the SIIT-DC Host Agent.
4. Architectural Overview
The following figure shows how an application (that is presumably
incompatible with standard SIIT-DC) is being made available to the
IPv4 Internet on the IPv4 address 192.0.2.4. The application will be
able to know that this is its local address and thus be able to
provide correct references to it in application payload.
The figure also shows how the same application is available over IPv6
on its IPv6 Service Address 2001:db8:12:34::3. This is included in
order to illustrate how native IPv6 connectivity is not impacted by
the SIIT-DC Host Agent, and also to illustrate how the address
assigned to the SIIT-DC Host Agent (2001:db8:12:34::4) is separate
from the primary IPv6 address of the server. It is however important
to note that the application in question does not have to be dual-
stack capable at all. IPv4-only applications would also be able to
operate behind a SIIT-DC Host Agent in the exact same manner.
Note that the figure below could be considered a more detailed view
of Customer A's FTP server from the example topology figure in
Appendix A of I-D.anderson-v6ops-siit-dc
[I-D.anderson-v6ops-siit-dc]. Both figures intentionally use the
exact same example IP addresses and prefixes.
SIIT-DC Host Agent Architecture
Anderson Expires March 19, 2015 [Page 4]
Internet-Draft SIIT-DC-2XLAT September 2014
+-------------------+ +----------------+
| 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.4 <=> 2001:db8:12:34::4 |
| | |
| +--------------<2001:db8:46::/96>-+
| |
| |
(the IPv6-only data centre network)
| |
| |
+--<2001:db8:12:34::3>-------<2001:db8:12:34::4>---+
| | | |
| | IPv6-only server | |
| | ================ | |
| | | |
| | +-------------<2001:db8:12:34::4>-+ |
| | | | |
| | | SIIT-DC Host Agent | |
| | | ================== | |
| | | | |
| | | Translation Prefix: | |
| | | 2001:db8:46::/96 | |
| | | | |
| | | Static Address Mapping: | |
| | | 192.0.2.4 <=> 2001:db8:12:34::4 | |
| | | | |
| | +---------------------<192.0.2.4>-+ |
| | | |
| | | |
| +-[2001:db8:12:34::3]--------------[192.0.2.4]-+ |
| | AF_INET6 AF_INET | |
Anderson Expires March 19, 2015 [Page 5]
Internet-Draft SIIT-DC-2XLAT September 2014
| | | |
| | Dual-stacked application | |
| | | |
| +----------------------------------------------+ |
+--------------------------------------------------+
Figure 1
5. Deployment Considerations
5.1. IPv6 Path MTU
The IPv6 Path MTU between the SIIT-DC Host Agent and the SIIT-DC
Gateway will typically be larger than the default value defined in
Section 4 of [RFC6145] (1280), as it will typically contained within
a single administrative domain. Therefore, it is recommended that
the IPv6 Path MTU configured in the SIIT-DC Host Agent is raised
accordingly. It is RECOMMENDED that the SIIT-DC Host Agent and the
SIIT-DC Gateway use identical configured IPv6 Path MTU values.
5.2. IPv4 MTU
In order to avoid fragmentation, it is RECOMMENDED that the virtual
IPv4 interface is configured with an MTU value identical to the
configured IPv6 Path MTU - 20. This ensures that the application may
do its part in avoiding IP-level fragmentation from occurring, e.g.,
by segmenting/fragmenting outbound packets at the application layer,
and advertising the maximum size its peer may use for inbound packets
(e.g., through the use of the TCP MSS option).
6. Acknowledgements
The author would like to especially thank the authors of 464XLAT
[RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne.
The architecture described by this document is merely an adaptation
of their work to a data centre environment, and could not have
happened without them.
The author would like also to thank the following individuals for
their contributions, suggestions, corrections, and criticisms: Fred
Baker, Tobias Brox, [YOUR NAME GOES HERE].
7. Requirements Language
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].
Anderson Expires March 19, 2015 [Page 6]
Internet-Draft SIIT-DC-2XLAT September 2014
8. IANA Considerations
This draft makes no request of the IANA. The RFC Editor may remove
this section prior to publication.
9. Security Considerations
This section discusses security considerations specific to the use of
a SIIT-DC Host Agent. See the Security Considerations in I-D
.anderson-v6ops-siit-dc [I-D.anderson-v6ops-siit-dc] for additional
security considerations applicable to the SIIT-DC architecture in
general.
9.1. Address Spoofing
If the SIIT-DC Host Agent receives an IPv4 packet from the
application from a different source address than the one it has a
Static Address Mapping for, the both the source and destination
addresses will be rewritten according to [RFC6052]. After undergoing
the reverse translation in the SIIT-DC Gateway, the resulting IPv4
packet routed to the IPv4 network will have a spoofed IPv4 source
address. The SIIT-DC Host Agent should therefore ensure that ingress
filtering (cf. BCP38 [RFC2827]) is used on the SIIT-DC Host Agent's
IPv4 interface, so that such packets are immediately discarded.
If the SIIT-DC Host Agent receives an IPv6 packet with both the
source and destination address equal to the one it has a Static
Address Mapping for, the resulting packet would appear to the
application as locally generated, as both the source address and the
destination address will be the same address as the one configured on
the virtual IPv4 interface. This could trick the application into
thinking this packet came from a trusted source, and give elevated
privileges accordingly. To prevent this, the SIIT-DC Host Agent
should discard any received IPv6 packets that have a source address
that is equal either to either the IPv4 (after undergoing [RFC6052]
translation) or the IPv6 address in the Static Address Mapping.
10. References
10.1. Normative References
[I-D.anderson-v6ops-siit-dc]
Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation in
IPv6 Data Centre Environments", draft-anderson-v6ops-siit-
dc-00 (work in progress), September 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Anderson Expires March 19, 2015 [Page 7]
Internet-Draft SIIT-DC-2XLAT September 2014
10.2. Informative References
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[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.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC
6877, April 2013.
Author's Address
Tore Anderson
Redpill Linpro
Vitaminveien 1A
0485 Oslo
NORWAY
Phone: +47 959 31 212
Email: tore@redpill-linpro.com
Anderson Expires March 19, 2015 [Page 8]
