Network Working Group T. Anderson
Internet-Draft Redpill Linpro
Intended status: Standards Track November 9, 2012
Expires: May 13, 2013
Stateless IP/ICMP Translation in IPv6 Data Centre Environments
draft-anderson-siit-dc-00
Abstract
This document describes the use of Stateless IP/ICMP Translation
(SIIT) in data centre environments in order to simultaneously
facilitate IPv6 deployment and IPv4 address conservation. It
describes the overall architecture, and provides guidelines for both
operators and implementers.
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 May 13, 2013.
Copyright Notice
Copyright (c) 2012 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 May 13, 2013 [Page 1]
Internet-Draft SIIT in Data Centre Environments November 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation and Goals . . . . . . . . . . . . . . . . . . . 3
1.1.1. Single Stack IPv6 Operation . . . . . . . . . . . . . 3
1.1.2. Stateless Operation . . . . . . . . . . . . . . . . . 4
1.1.3. No Loss of End User's Source Address . . . . . . . . . 4
1.1.4. No Forklift Upgrades Required . . . . . . . . . . . . 4
1.1.5. No Architectural Dependency on IPv4 . . . . . . . . . 5
1.2. Comparison to Other IPv6 Migration Strategies . . . . . . 5
1.2.1. IPv4-only Service with Translation for IPv6 Users . . 5
1.2.2. Dual Stack . . . . . . . . . . . . . . . . . . . . . . 5
2. Architectural Overview . . . . . . . . . . . . . . . . . . . . 6
2.1. DNS Configuration . . . . . . . . . . . . . . . . . . . . 8
2.2. Example Packet Flow . . . . . . . . . . . . . . . . . . . 8
3. Deployment Guidelines for Operators . . . . . . . . . . . . . 10
3.1. Choice of Application . . . . . . . . . . . . . . . . . . 10
3.2. Choice of Translation Prefix . . . . . . . . . . . . . . . 11
3.3. Routing Considerations . . . . . . . . . . . . . . . . . . 11
3.4. Location of the Translators . . . . . . . . . . . . . . . 11
3.5. Migration from Dual Stack . . . . . . . . . . . . . . . . 12
3.6. Packet Size and Fragmentation Considerations . . . . . . . 12
3.6.1. IP Header Size Difference . . . . . . . . . . . . . . 13
3.6.2. Minimum Path MTU Difference . . . . . . . . . . . . . 13
3.6.3. "Atomic Fragments" . . . . . . . . . . . . . . . . . . 14
4. Implementation Requirements . . . . . . . . . . . . . . . . . 14
4.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 14
4.2. Static Address Mapping Function . . . . . . . . . . . . . 14
4.3. Support for Increasing the IPv6 Path MTU . . . . . . . . . 15
4.4. Support for Disabling "Atomic Fragments" . . . . . . . . . 15
4.5. Feature for Handling IPv4 Path MTUs Lower than 1260 . . . 15
4.6. Loop Prevention Mechanism . . . . . . . . . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
6. Requirements Language . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8.1. Mistaking the Translation Prefix for a Trusted Network . . 16
8.2. Packets Looping Through the SIIT Function . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Anderson Expires May 13, 2013 [Page 2]
Internet-Draft SIIT in Data Centre Environments November 2012
1. Introduction
This document describes deploying SIIT [RFC6145] as a network-centric
stateless translation service that allow a data centre operator or
Internet content provider run his 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.
1.1. Motivation and Goals
Historically, dual stack [RFC4213] 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, however,
dual stack operation has a number of disadvantages compared to single
stack operation, in particular 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.
Therefore, a better approach was needed. The design goals were, in
no particular order:
o To promote the deployment of native IPv6 services
o To provide IPv4 service availability for legacy users with no loss
of performance or functionality
o To ensure that that the legacy users' IPv4 addresses remain
available to the servers and applications
o To conserve and maximise the utilisation of IPv4 addresses
o To avoid introducing more complexity than absolutely necessary,
especially on the servers and applications
o To be easy to scale and deploy in a fault-tolerant manner
SIIT meets all of these requirements, which will be elaborated on in
the following subsections.
1.1.1. Single Stack IPv6 Operation
SIIT 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
Anderson Expires May 13, 2013 [Page 3]
Internet-Draft SIIT in Data Centre Environments November 2012
staff do not need to concern themselves with.
Obviously, this will promote universal IPv6 deployment for all the
provider's services and applications.
1.1.2. Stateless Operation
Unlike other solutions that provide either dual stack availability to
single-stack services (e.g., Stateful NAT64 [RFC6146] and Layer-4/7
proxies), or that provide conservation of IPv4 addresses (e.g., NAT44
[RFC3022]), a SIIT gateway does not keep any state between each
packet in a single connection/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.
This not only allows individual SIIT gateways to easily attain "line
rate" performance, it also allows for per-packet load balancing
between multiple gateways using Equal-Cost Multipath Routing
[RFC2991]. Asymmetric routing is also unproblematic, which makes it
easy to avoid traffic trampolines, as the prefixes involved may be
anycasted from all the SIIT gateways in the provider's network.
Finally, stateless operation means that high availability is easily
achieved. If an SIIT gateway should fail, its traffic can be re-
routed onto another SIIT gateway using completely standard IP routing
protocols. This will not impact existing flows any more than what
any other IP re-routing event would.
1.1.3. No Loss of End User's Source Address
SIIT 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 his IPv4 address, which is useful for performing
tasks like Geo-Location, logging, abuse handling, and so forth.
1.1.4. No Forklift Upgrades Required
Except for the introduction of the SIIT gateways themselves, there is
no change required in the network, servers, applications, or anywhere
else to specifically support SIIT, 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 is practically
invisible. It will work with any standards-compliant IPv4 or IPv6
stack.
Anderson Expires May 13, 2013 [Page 4]
Internet-Draft SIIT in Data Centre Environments November 2012
1.1.5. No Architectural Dependency on IPv4
SIIT will allow an ICP or data centre operator to build their
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 gateways. Therefore, by deploying native IPv6
along with SIIT, operators will avoid future migration or deployment
projects relating to IPv6 roll-out and/or IPv4 sun-setting.
1.2. Comparison to Other IPv6 Migration Strategies
1.2.1. IPv4-only Service with Translation for IPv6 Users
Typically, this migration strategy involves having an IPv4-only
application stack, with some device in front that the IPv6 client
connect to, who will then translate or proxy the traffic to the IPv4-
only system. This approach is probably the easiest to retrofit to an
existing IPv6 service environment, however it does have a few
shortcomings not shared by SIIT. In particular:
o No conservation of IPv4 addresses
o The translator/proxy must be a stateful device, requiring traffic
to flow symmetrically across a single instance, in turn giving the
solution poor scaling properties and routing flexibility
o A fail-over event will disrupt all active flows, unless there is
some state replication mechanism (which would likely increase
complexity and hurt performance and scaling properties)
o Loss of the client's source IP address, if it cannot be injected
into application-layer headers such as HTTP's X-Forwarded-For
(which is impossible if the application layer is using encryption)
1.2.2. Dual Stack
Dual stack, unlike SIIT, considerably increases complexity and
operational overhead compared to single stack operation for a number
of reasons. Some examples of this include:
o Duplicate work for design, set-up, documentation, and monitoring
o Duplicate ACLs in both network components and applications
o An exponential increase in possible failure scenarios
Anderson Expires May 13, 2013 [Page 5]
Internet-Draft SIIT in Data Centre Environments November 2012
o Increased application development and maintenance costs
o Increased need for staff training and competency
Furthermore, dual stack does not help conserve IPv4 addresses.
2. Architectural Overview
This section attempts to explain the basic SIIT architecture by
describing an example topology of a data centre hosting two IPv6-
only customers:
o Alice, operating a publicly available web service.
o Bob, operating publicly available DNS and MX service.
Since both Alice and Bob's server installations contain other servers
that provide internal services, if they had used IPv4, they each
would have needed their server LANs to be provisioned with at minimum
a /29, thereby consuming 16 IPv4 addresses. With SIIT, the IPv4
address consumption is reduced to 3 - the same number of publicly
available services.
Anderson Expires May 13, 2013 [Page 6]
Internet-Draft SIIT in Data Centre Environments November 2012
Example SIIT Topology
+------------------+ +------------------+
| IPv4-only user 1 | | IPv4-only user 2 |
| 203.0.113.50 | | 192.0.2.10 |
+--------+---------+ +--------+---------+
| |
\-----------\ /----------/
| |
| |
(The IPv4 Internet) | |
+---------------------[ IPv4 interface ]-----------------------+
| |
| SIIT Gateway |
| |
| IPv4 service address pool: 198.51.0.0/24 |
| Static address mapping 1: 198.51.0.1 <=> 2001:db8:12:34::c |
| Static address mapping 2: 198.51.0.2 <=> 2001:db8:ab:cd::1 |
| Static address mapping 3: 198.51.0.3 <=> 2001:db8:ab:cd::f |
| Translation prefix: 2001:db8:46::/96 |
| |
+---------------------[ IPv6 interface ]-----------------------+
(IPv6-only data centre) | |
| |
| |
Server LAN Alice | | Server LAN Bob
2001:db8:12:34::/64 | | 2001:db8:ab:cd::/64
+-------+-------+-------+ +---+-------+--------+--------+
| | | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +---+---+ +--+--+
| www | | nfs | | sql | | mta | | a/v | | iscsi | | dns |
| ::1 | | ::2 | | ::3 | | ::f | | ::e | | ::d | | ::c |
+-----+ +-----+ +-----+ +-----+ +-----+ +-------+ +-----+
Figure 1
198.51.0.0/24 is allocated as a pool from which individual IPv4
service addresses are drawn. The provider must route this prefix to
the SIIT 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 gateway's
IPv4 interface.
The static address mappings are used for translating the service's
IPv6 address into IPv4 and vice versa. When translating from IPv4 to
IPv6, any IPv4 address found in the list of static mappings will be
Anderson Expires May 13, 2013 [Page 7]
Internet-Draft SIIT in Data Centre Environments November 2012
rewritten to its corresponding IPv6 address, and vice versa when
translating from IPv6 to IPv4.
2001:db8:46::/96 is the IPv6 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 section 2.2 of [RFC6052]. This algorithmic mapping has a
lower precedence than the static mappings.
The SIIT 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 gateways may exist simultaneously in an operators
infrastructure, as long as they all have the same translation prefix
and list of static mappings configured.
2.1. DNS Configuration
The native IPv6 address of the publicly available services should be
registered in DNS using AAAA records, while the corresponding IPv4
address (according to the static mapping), should be registered using
an A record. This results in the following DNS records:
www.alice.tld. IN AAAA 2001:db8:12:34::1
www.alice.tld. IN A 198.51.0.2
mta.bob.tld. IN AAAA 2001:db8:ab:cd::f
mta.bob.tld. IN A 198.51.0.3
dns.bob.tld. IN AAAA 2001:db8:12:34::c
dns.bob.tld. IN A 198.51.0.1
2.2. Example Packet Flow
In this example, "IPv4-only user 2" initiates a request to Alice's
web server. He starts by looking up the IPv4 address of
"www.alice.tld" in DNS, and attempts to connect to this address on
port 80 by transmitting the following IPv4 packet:
+-----------------------------------------------+
| IP Version: 4 |
| Source Address: 192.0.2.10 |
| Destination Address: 198.51.0.2 |
| Protocol: TCP |
|-----------------------------------------------|
| TCP SYN [...] |
+-----------------------------------------------+
This packet is then routed over the Internet to the (nearest) SIIT
Anderson Expires May 13, 2013 [Page 8]
Internet-Draft SIIT in Data Centre Environments November 2012
gateway, which will translate it into the following IPv6 packet and
forward it into the IPv6 network:
+-----------------------------------------------+
| IP Version: 6 |
| Source Address: 2001:db8:46::192.0.2.10 |
| Destination Address: 2001:db8:12:34::1 |
| Next Header: TCP |
|-----------------------------------------------|
| TCP SYN [...] |
+-----------------------------------------------+
The destination address was translated according to the configured
static mapping, while the source address was translated according to
the [RFC6052] mapping (because it did not match any static mappings).
The rest of the IP header was translated according to [RFC6145]. The
Layer 4 payload is copied verbatim, with the exception of the TCP
checksum being recalculated.
Note that the IPv6 address 2001:db8:46::192.0.2.10 may also be
expressed as 2001:db8:46::c000:20a, cf. section 2.2 of [RFC2373].
Next, Alice's web server receives this IPv6 packet and responds to it
like it would with any other IPv6 packet:
+-----------------------------------------------+
| IP Version: 6 |
| Source Address: 2001:db8:12:34::1 |
| Destination Address: 2001:db8:46::192.0.2.10 |
| Next Header: TCP |
|-----------------------------------------------|
| TCP SYN+ACK [...] |
+-----------------------------------------------+
The response packet is routed to the (nearest) SIIT gateway's IPv6
interface, which will translate it back to IPv4 as follows:
+-----------------------------------------------+
| IP Version: 4 |
| Source Address: 198.51.0.2 |
| Destination Address: 192.0.2.10 |
| Protocol: TCP |
|-----------------------------------------------|
| TCP SYN+ACK [...] |
+-----------------------------------------------+
This time, the source address matched the static mapping, while the
destination address was translated according to [RFC6052]. The rest
Anderson Expires May 13, 2013 [Page 9]
Internet-Draft SIIT in Data Centre Environments November 2012
of the packet was translated according to [RFC6145].
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.
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.
3. Deployment Guidelines for Operators
3.1. Choice of Application
As noted in [RFC2663], [RFC2993], and [RFC3022], higher-level
protocols that embed addresses as part of their payload, will most
likely not work through any form of address translation, including
SIIT. As a general rule, if an application layer protocol does work
through standard NAT44 (see [RFC3235]), it will most likely work
through SIIT as well.
It is recommended that an initial deployment of SIIT is used for
applications where IPv4-only nodes on the Internet initiate traffic
towards the IPv6-only services. While it is possible to combine SIIT
with DNS64 [RFC6147] or similar mechanisms in order to allow an IPv6-
only server to initiate communication with IPv4 nodes through an SIIT
gateway, this may be more complicated to implement, as the server
must ensure to always use the address statically mapped on the SIIT
gateway as the source when initiating communication.
In particular, HTTP [RFC2616] is a good choice of an application
protocol to start deploying SIIT with, as it is both ubiquitous and
known to work very well through address translation.
Note that implementations of SIIT may bundle Application Level
Gateways (ALGs) to add specific support for certain application
protocols that would otherwise break, similar to what is commonly
done with NAT44 implementations. If ALGs are being used, care must
be taken to ensure that all the translators in the network all have
compatible ALGs.
Anderson Expires May 13, 2013 [Page 10]
Internet-Draft SIIT in Data Centre Environments November 2012
3.2. Choice of Translation Prefix
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 in his network,
or Stateful NAT64 [RFC6146], an NSP must be used anyway for all but
one of those deployments.
Furthermore, the WKP cannot be used in inter-domain routing. By
using an NSP, a provider will have the possibility to sell SIIT
service to other operators.
For these reasons, this document recommends that an NSP is used.
Section 3.3 of [RFC6052] discusses the choice of translation prefix
in more detail.
The prefix may use any of the lengths described in section 2.2 of
[RFC6052], 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::192.0.2.10" (see section 2.4 of [RFC6052]), 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.
3.3. Routing Considerations
The IPv4 service address prefix(es) and the IPv6 translation prefix
may be routed to the SIIT gateway(s) as any other IPv4 or IPv6 route
in the provider's network.
If more than one SIIT 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 translator, reducing or eliminating traffic trampolines,
as well as provide high availability - if one translator fails, the
dynamic routing protocol will automatically redirect the traffic to
the next-best translator.
3.4. Location of the Translators
In order to prevent traffic trampolines, it is optimal to place the
translators as close as possible to the direct path between the
Anderson Expires May 13, 2013 [Page 11]
Internet-Draft SIIT in Data Centre Environments November 2012
servers and the end users.
Ideally, they are implemented as a logical function within the IP
routers would handle the traffic anyway (if it wasn't to be
translated). This way, the translation service would not need
separate networks ports to be assigned (which might become saturated
and impacted the service), 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 translators - thus allowing the operator to reclaim
IPv4 addresses from the network infrastructure that may instead be
used for translated services.
3.5. Migration from Dual Stack
While this document discusses the use of IPv6-only servers and
applications, there is no technical requirement that the servers are
IPv4 free. SIIT works equally well for a 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.
For high-volume services migrating to SIIT 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 one(s).
3.6. Packet Size and Fragmentation Considerations
There are two key differences between IPv4 and IPv6 relating to
packet sizes that one should consider when deploying SIIT. They
result in a few problematic corner cases, which can be dealt with in
a few different ways.
The operator may find that relying on fragmentation in the IPv6
domain is undesired or even operationally impossible [FRAGDROP]. For
this reason, the recommendations in this section seeks to minimise
the use of IPv6 fragmentation.
Unless otherwise stated, this section assumes that the MTU in both
the IPv4 and IPv6 domains is 1500 bytes.
Anderson Expires May 13, 2013 [Page 12]
Internet-Draft SIIT in Data Centre Environments November 2012
3.6.1. IP Header Size Difference
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.
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.
For other transport protocols, full-size IPv4 packets with the DF
flag cleared will need to be fragmented by the SIIT gateway. The
only way to avoid this is to increase the Path MTU between the SIIT
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. However, if the server's
IPv6 implementation allows the MTU to be set differently for specific
destinations, it MAY be increased to 1520 for destinations within the
translation prefix specifically.
3.6.2. Minimum Path MTU Difference
The minimum allowed MTU in IPv6 is 1280 bytes, while no such
restriction exists in IPv4. 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.
By default, an SIIT 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 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 section 5 of [RFC2460]:
o It may reduce its Path MTU value to the value indicated in the
Packet Too Big. This causes no problems for the SIIT function.
o It may reduce its Path MTU value to 1280, and also include a
Fragmentation header in each subsequent packet sent to that
destination. This instructs the SIIT gateway to clear the DF flag
in the resulting IPv4 packet, and also provides the Identification
value.
Anderson Expires May 13, 2013 [Page 13]
Internet-Draft SIIT in Data Centre Environments November 2012
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 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. Section 4.5.
3.6.3. "Atomic Fragments"
By default, an SIIT gateway will include a Fragmentation header in
the resulting IPv6 packet when translating from an IPv4 packet with
the DF flag cleared, cf. section 4 of [RFC6145].
This happens even though the resulting IPv6 packets aren't actually
fragmented into several pieces, resulting in "Atomic Fragments"
[ATOMFRAG]. This is generally not useful in a data centre
environment, and it is therefore recommended that this behaviour is
disabled at the SIIT gateways. See Section 4.4.
4. Implementation Requirements
[RFC6145] and [RFC6052] specifies the basic SIIT gateway. However,
they specify some optional features that are very desirable when
deploying SIIT in a data centre environment. This section list which
additional features are required for an SIIT gateway optimised for a
data centre environment.
4.1. Basic Requirements
The implementation MUST implement [RFC6145] with the algorithmic
address mapping defined in [RFC6052]. It MUST NOT create any per-
session state under any circumstance.
4.2. Static Address Mapping Function
The implementation MUST allow the operator to configure an arbitrary
number of static mappings which override the default [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.
An example of such a bidirectional static mapping would be:
Anderson Expires May 13, 2013 [Page 14]
Internet-Draft SIIT in Data Centre Environments November 2012
o 198.51.0.1 <=> 2001:db8:12:34::c
To accomplish the same using unidirectional mappings, the following
two mappings must instead be configured:
o 198.51.0.1 => 2001:db8:12:34::c
o 2001:db8:12:34::c => 198.51.0.1
In both cases, if the gateway receives an IPv6 packet that has 2001:
db8:12:34::c in either of the source and destination fields of the IP
header, it MUST rewrite this field to 198.51.0.1 when translating to
IPv4. Similarly, if the gateway receives an IPv4 packet that has
198.51.0.1 as the either the source or destination fields of the IP
header, it MUST rewrite this field to 2001:db8:12:34::c. For all
IPv4 or IPv6 source or destination field values for which there is no
static mapping, [RFC6052] mapping MUST be used.
4.3. Support for Increasing the IPv6 Path MTU
In order to prevent unnecessary use of the IPv6 Fragmentation header,
the implementation MUST support increasing the IPv6 Path MTU from its
default value of 1280, as described in section 4 of [RFC6145].
4.4. Support for Disabling "Atomic Fragments"
The translator MUST provide a configuration function that allows the
translator not to include the Fragment Header for non-fragmented IPv6
packets, cf. section 4 of [RFC6145].
4.5. Feature for Handling IPv4 Path MTUs Lower than 1260
In order to prevent unnecessary fragments, the implementation MUST
support a feature which, if enabled by the operator, changes the
translator's default behaviour accordingly:
o 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.
o 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
Identification value is generated. The translator MUST NOT
generate any state as a result of this.
This is a modified version of the second approach described in
section 6 of [RFC6145]. The default state of the feature SHOULD be
disabled.
Anderson Expires May 13, 2013 [Page 15]
Internet-Draft SIIT in Data Centre Environments November 2012
For the definition of an "Atomic Fragment", see [ATOMFRAG].
4.6. Loop Prevention Mechanism
As noted in Section 8.2, there is a potential for packets looping
through the SIIT function if it receives an IPv4 packet for which
there is no static 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 function.
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.
5. Acknowledgements
TBD
6. 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].
7. IANA Considerations
This draft makes no request of the IANA.
8. Security Considerations
8.1. Mistaking the Translation Prefix for a Trusted Network
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.
Anderson Expires May 13, 2013 [Page 16]
Internet-Draft SIIT in Data Centre Environments November 2012
8.2. Packets Looping Through the SIIT Function
The SIIT gateway receives an IPv4 packet destined to an address for
which there is no static mapping, its destination address will be
rewritten according to [RFC6052], making the resulting IPv6 packet
have a destination address within the translation prefix, which is
likely routed to back to the SIIT function. This will cause the
packet to loop until its Time To Live / Hop Limit reaches zero,
potentially creating a Denial Of Service vulnerability.
To avoid this, it should be ensured that packets sent to IPv4
destinations addresses for which there are no static mappings, or
whose resulting IPv6 address does not have a more-specific route to
the IPv6 network, are immediately discarded.
9. References
9.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.
9.2. Informative References
[ATOMFRAG]
Gont, F., "Processing of IPv6 "atomic" fragments",
December 2011, <draft-gont-6man-ipv6-atomic-fragments-00>.
[FRAGDROP]
Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
M., and T. Taylor, "Why Operators Filter Fragments and
What It Implies", October 2012, <http://tools.ietf.org/
html/draft-taylor-v6ops-fragdrop-00>.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Anderson Expires May 13, 2013 [Page 17]
Internet-Draft SIIT in Data Centre Environments November 2012
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011.
Author's Address
Tore Anderson
Redpill Linpro
Herregaardsveien 8B
NO-1168 Oslo
NORWAY
Phone: +47 959 31 212
Email: tore.anderson@redpill-linpro.com
Anderson Expires May 13, 2013 [Page 18]