draft-ietf-v6ops-siit-dc-00.txt   draft-ietf-v6ops-siit-dc-01.txt 
IPv6 Operations T. Anderson IPv6 Operations T. Anderson
Internet-Draft Redpill Linpro Internet-Draft Redpill Linpro
Intended status: Standards Track December 18, 2014 Intended status: Informational June 28, 2015
Expires: June 21, 2015 Expires: December 30, 2015
SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments
draft-ietf-v6ops-siit-dc-00 draft-ietf-v6ops-siit-dc-01
Abstract Abstract
This document describes SIIT-DC, an extension to the Stateless IP/ This document describes the use of the Stateless IP/ICMP Translation
ICMP Translation (SIIT) algorithm, that makes it ideally suited for (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this
use in IPv6 data centre environments. SIIT-DC simultaneously deployment model, traffic from legacy IPv4-only clients on the
facilitates IPv6 deployment and IPv4 address conservation. The Internet is translated to IPv6 when reaches the IDC operator's
overall SIIT-DC architecture is described, as well as guidelines for network infrastructure. From that point on, it is treated just as if
operators. Finally, the normative implementation requirements are it was traffic from any other IPv6-capable end user. This
described, as a list of additions and changes to SIIT. facilitates a single-stack IPv6-only network infrastructure, as well
as efficient utilisation of public IPv4 addresses.
The primary audience is IDC operators who are deploying IPv6, running
out of available IPv4 addresses, and/or feel that dual stack causes
undesirable operational complexity.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2015. This Internet-Draft will expire on December 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation and Goals . . . . . . . . . . . . . . . . . . 3 1.1. Single Stack IPv6 Operation . . . . . . . . . . . . . . . 3
1.1.1. Single Stack IPv6 Operation . . . . . . . . . . . . . 4 1.2. Stateless Operation . . . . . . . . . . . . . . . . . . . 4
1.1.2. Stateless Operation . . . . . . . . . . . . . . . . . 4 1.3. IPv4 Address Conservation . . . . . . . . . . . . . . . . 4
1.1.3. IPv4 Address Conservation . . . . . . . . . . . . . . 5 1.4. Clients' IPv4 Source Addresses Visible to Applications . 5
1.1.4. No Loss of End User's IPv4 Source Address . . . . . . 5 1.5. Compatible with Standard IPv4 and IPv6 Stacks . . . . . . 5
1.1.5. Compatible with Standard IPv6 Implementations . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.6. No Architectural Dependency on IPv4 . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 7 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 7
3.1. DNS Configuration . . . . . . . . . . . . . . . . . . . . 9 3.1. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 9 4. Deployment Considerations and Guidelines . . . . . . . . . . 10
4. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 11 4.1. Application/Device Support for IPv6 . . . . . . . . . . . 10
4.1. Application Support for NAT . . . . . . . . . . . . . . . 12 4.2. Application Support for NAT . . . . . . . . . . . . . . . 10
4.2. Application Support for IPv6 . . . . . . . . . . . . . . 12 4.3. Application Communication Pattern . . . . . . . . . . . . 10
4.3. Application Communication Pattern . . . . . . . . . . . . 12 4.4. Choice of Translation Prefix . . . . . . . . . . . . . . 11
4.4. Choice of Translation Prefix . . . . . . . . . . . . . . 13 4.5. Routing Considerations . . . . . . . . . . . . . . . . . 12
4.5. Routing Considerations . . . . . . . . . . . . . . . . . 13 4.6. Location of the SIIT-DC Border Relays . . . . . . . . . . 12
4.6. Location of the SIIT-DC Gateways . . . . . . . . . . . . 14 4.7. Migration from Dual Stack . . . . . . . . . . . . . . . . 13
4.7. Migration from Dual Stack . . . . . . . . . . . . . . . . 15 4.8. Translation of ICMPv6 Errors to IPv4 . . . . . . . . . . 13
4.8. Packet Size and Fragmentation Considerations . . . . . . 15 4.9. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 13
4.8.1. IPv4/IPv6 Header Size Difference . . . . . . . . . . 16 4.9.1. IPv4/IPv6 Header Size Difference . . . . . . . . . . 14
4.8.2. IPv6 Atomic Fragments . . . . . . . . . . . . . . . . 16 4.9.2. IPv6 Atomic Fragments . . . . . . . . . . . . . . . . 14
4.8.3. Minimum Path MTU Difference Between IPv4 and IPv6 . . 17 4.9.3. Minimum Path MTU Difference Between IPv4 and IPv6 . . 15
5. Implementation Requirements . . . . . . . . . . . . . . . . . 18 4.10. IPv4-translatable IPv6 Service Addresses . . . . . . . . 16
5.1. Compliance with RFC6145 and RFC6052 . . . . . . . . . . . 18 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Static Address Mapping Function . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5.3. Support for Increasing the IPv6 Path MTU . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.4. Loop Prevention Mechanism . . . . . . . . . . . . . . . . 20 7.1. Mistaking the Translation Prefix for a Trusted Network . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Requirements Language . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 Appendix A. Complete SIIT-DC IDC topology example . . . . . . . 20
9.1. Mistaking the Translation Prefix for a Trusted Network . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Packets Looping Through the SIIT-DC Function . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Complete SIIT-DC topology example . . . . . . . . . 23
Appendix B. Comparison to Other Deployment Approaches . . . . . 26
B.1. IPv4-only . . . . . . . . . . . . . . . . . . . . . . . . 26
B.2. IPv4-only + NAPT44 . . . . . . . . . . . . . . . . . . . 26
B.3. IPv4-only + NAT64 . . . . . . . . . . . . . . . . . . . . 28
B.4. Dual Stack . . . . . . . . . . . . . . . . . . . . . . . 29
B.5. Partial Dual Stack (IPv6-only back-end) . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
SIIT-DC is an extension of SIIT [RFC6145] that provides a network-
centric stateless translation service that allows a data centre
operator or Internet Content Provider (ICP) to run a 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] [RFC6883] has been the recommended Historically, dual stack [RFC4213] [RFC6883] has been the recommended
way to transition from an IPv4-only environment to one capable of way to transition from a legacy IPv4-only environment to one capable
serving IPv6 users. However, for data centre operators and Internet of serving IPv6 users. However, for IDC operators, dual stack
content providers, dual stack operation has a number of disadvantages operation has a number of disadvantages compared to single stack
compared to single stack operation. In particular, running two operation. In particular, running two protocols rather than one
protocols rather than one results in increased complexity and results in increased complexity and operational overhead, with little
operational overhead, with a very low expected return on investment return on investment for as long as large parts of the public
in the short to medium term while few end-users only have Internet remains predominantly IPv4-only. Furthermore, the dual
connectivity to the IPv6 Internet. Furthermore, the dual stack stack approach does not in any way help with the depletion of the
approach does not in any way help with the depletion of the IPv4 IPv4 address space, which at the time of writing is a pressing
address space. concern in most parts of the world.
Therefore, some operators may prefer an approach in which they only Therefore, some IDC operators may instead prefer an approach in which
need to operate one protocol in the data centre as they prepare for they only need to operate one protocol in the data centre as they
the future. The design goals are: prepare for the future. SIIT-DC is one such approach. Its design
goals include:
o Promote the deployment of native IPv6 services (cf. [RFC6540]). o Promote the deployment of native IPv6 services (cf. [RFC6540]).
o Provide IPv4 service availability for legacy users with no loss of o Provide IPv4 service availability for legacy users with no loss of
performance or functionality. performance or functionality.
o To ensure that that the legacy users' IPv4 addresses remain o To ensure that that the legacy users' IPv4 addresses remain
available to the servers and applications. visible to the nodes and applications.
o To conserve and maximise the utilisation of IPv4 addresses. o To conserve and maximise the utilisation of the operator's public
IPv4 addresses.
o To avoid introducing more complexity than absolutely necessary, o To avoid introducing more complexity than absolutely necessary,
especially on the servers and applications. especially on the nodes and applications.
o To be easy to scale and deploy in a fault-tolerant manner. o To be easy to scale and deploy in a fault-tolerant manner.
The following subsections elaborates on how SIIT-DC meets these The following subsections elaborates on how SIIT-DC meets these
goals. goals.
1.1.1. Single Stack IPv6 Operation 1.1. Single Stack IPv6 Operation
SIIT-DC allows an operator to build their applications on an SIIT-DC allows IDC operators to build their infrastructure and
IPv6-only foundation. IPv4 end-user connectivity becomes a service applications on an IPv6-only foundation. IPv4 end-user connectivity
provided by the network, which systems administration and application becomes a service provided by the network, which systems
development staff do not need to concern themselves with. administration and application development staff do not need to
concern themselves with. This promotes universal IPv6 deployment for
the IDC operator's services and applications.
Obviously, this will promote universal IPv6 deployment for all of the SIIT-DC requires no special support or change from the underlying
provider's services and applications. IPv6 infrastructure, it is compatible with all standard IPv6
networks. Traffic between IPv6-enabled end users and IPv6-enabled
services will always be transported native end-to-end; SIIT-DC does
not intercept or handle native IPv6 traffic at all.
It is worth noting that SIIT-DC requires no special support or change When the day comes to discontinue all support for IPv4, no change
from the underlying IPv6 infrastructure, it will work with any kind needs to be made to the overall architecture - it's only a matter of
of IPv6 network. Traffic between IPv6-enabled end users and shutting off the BRs. Operators who deploy native IPv6 along with
IPv6-enabled services will always be native, and SIIT-DC will not be SIIT-DC will thus avoid requiring any future migration or deployment
involved in it at all. projects relating to IPv6 deployment and/or IPv4 sun-setting.
1.1.2. Stateless Operation 1.2. Stateless Operation
Unlike other solutions that provide either dual stack availability to Unlike other solutions that provide either dual stack availability to
single-stack services (e.g., Stateful NAT64 [RFC6146] and Layer-4/7 single-stack services (e.g., Stateful NAT64 [RFC6146] and Layer-4/7
proxies), or that provide conservation of IPv4 addresses (e.g., proxies), or that provide conservation of IPv4 addresses (e.g.,
NAPT44 [RFC3022]), a SIIT-DC Gateway does not keep any state between NAPT44 [RFC3022]), SIIT-DC does not keep any state between each
each packet in a single connection or flow. In this sense it packet in a single connection or flow. In this sense it operates
operates exactly like a normal IP router, and has similar scaling exactly like a regular IP router, and has similar scaling properties
properties - the limiting factors are packets per second and - the limiting factors are packets per second and bandwidth. The
bandwidth. The number of concurrent flows and flow initiation rates number of concurrent flows and flow initiation rates are irrelevant
are irrelevant for performance. for performance.
This not only allows individual SIIT-DC Gateways to easily attain This not only allows individual BRs to easily attain "line rate"
"line rate" performance, it also allows for per-packet load balancing performance, it also allows for per-packet load balancing between
between multiple SIIT-DC Gateways using Equal-Cost Multipath Routing multiple BRs using Equal-Cost Multipath Routing [RFC2991].
[RFC2991]. Asymmetric routing is also acceptable, which makes it Asymmetric routing is also acceptable, which makes it easy to avoid
easy to avoid sub-optimal traffic patterns; the prefixes involved may sub-optimal traffic patterns; the prefixes involved may be anycasted
be anycasted from all the SIIT-DC Gateways in the provider's network, from all the BRs in the provider's network, thus ensuring that the
thus ensuring that the most optimal path through the network is used, most optimal path through the network is used, even where the optimal
even where the optimal path in one direction differs from the optimal path in one direction differs from the optimal path in the opposite
path in the opposite direction. direction.
Finally, stateless operation means that high availability is easily Finally, stateless operation means that high availability is easily
achieved. If an SIIT-DC Gateway should fail, its traffic can be re- achieved. If a BR should fail, its traffic can be re-routed onto
routed onto another SIIT-DC Gateway using a standard IP routing another BR using a standard IP routing protocol. This does not
protocol. This does not impact existing flows any more than what any impact existing flows any more than what any other IP re-routing
other IP re-routing event would. event would.
1.1.3. IPv4 Address Conservation 1.3. IPv4 Address Conservation
In most parts of the world, it is difficult or even impossible to In most parts of the world, it is difficult or even impossible to
obtain generously sized IPv4 allocations from the Regional Internet obtain generously sized IPv4 delegation from the Internet Numbers
Registries. The resulting scarcity in turn impacts individual end Registry System [RFC7020]. The resulting scarcity in turn impacts
users and operators, which might be forced to purchase IPv4 addresses individual end users and operators, which might be forced to purchase
from other operators in order to cover their needs. This process can IPv4 addresses from other operators in order to cover their needs.
be risky to business continuity, in the case no suitable block for This process can be risky to business continuity, in the case no
sale can be located, and/or turn out to be prohibitively expensive. suitable block for sale can be located, and/or turn out to be
Even so, a data centre operator will find that providing IPv4 service prohibitively expensive. In spite of this, an IDC operator will find
is essential, as a large share of the Internet users still does not that providing IPv4 service remains essential, as a large share of
have IPv6 connectivity. the Internet end users still do not have IPv6 connectivity.
A key goal of SIIT-DC is to help reduce a data centre operator's IPv4 A key goal of SIIT-DC is to help reduce a data centre operator's IPv4
address requirement to the absolute minimum, by allowing the operator address requirement to the absolute minimum, by allowing the operator
to remove them entirely from components that do not need to to remove them entirely from nodes and applications that do not need
communicate with endpoints in the IPv4 Internet. One example would to communicate with endpoints in the IPv4 Internet. One example
be servers that are operating in a supporting/back-end role and only would be servers that are operating in a supporting/back-end role and
communicates with to other servers (database servers, file servers, only communicates with to other servers (database servers, file
and so on). Another example would be the network infrastructure servers, and so on). Another example would be the network
itself (router-to-router links, loopback addresses, and so on). infrastructure itself (router-to-router links, loopback addresses,
Furthermore, as LAN prefix sizes must always be rounded up to the and so on). Furthermore, as LAN prefix sizes must always be rounded
nearest power of two (or larger, if one reserves space for future up to the nearest power of two (or larger, if one reserves space for
growth), even more IPv4 addresses will often end up being wasted future growth), even more IPv4 addresses will often end up being
without even being used. wasted without even being used.
With SIIT-DC, the operator can remove these valuable IPv4 addresses With SIIT-DC, the operator can remove these valuable IPv4 addresses
from his back-end servers and network infrastructure, and reassign from his back-end servers and network infrastructure, and reassign
them to the SIIT-DC service as IPv4 Service Addresses. There is no them to the SIIT-DC service as IPv4 Service Addresses. There exists
requirement that IPv4 Service Addresses are assigned in an aggregated no requirement that IPv4 Service Addresses are assigned in an
manner, so there is nothing lost due to infrastructure overhead; aggregated manner, so there is nothing lost due to infrastructure
every single IPv4 address assigned to SIIT-DC can be used an IPv4 overhead; every single IPv4 address assigned to SIIT-DC can be used
Service Address. an IPv4 Service Address.
1.1.4. No Loss of End User's IPv4 Source Address
SIIT-DC will map the entire end-user's IPv4 source address into an
predefined IPv6 translation prefix. This ensures that there is no
loss of information; the end-user's IPv4 source address remains
available to the server/application, allowing it to perform tasks
like Geo-Location, logging, abuse handling, and so forth.
1.1.5. Compatible with Standard IPv6 Implementations 1.4. Clients' IPv4 Source Addresses Visible to Applications
Except for the introduction of the SIIT-DC Gateways themselves, no SIIT-DC uses the [RFC6052] algorithm to map the entire end-user's
change to the network, servers, applications, or anything else is IPv4 source address into an predefined IPv6 Translation Prefix. This
required in order to support SIIT-DC. SIIT-DC is practically ensures that there is no loss of information; the end-user's IPv4
invisible from the point of view of the the IPv4 clients, the IPv6 source address remains available to the application, allowing it to
servers, the IPv6 data centre network, and the IPv4 Internet. SIIT- perform tasks like Geo-Location, logging, abuse handling, and so
DC interoperates with all standards-compliant IPv4 or IPv6 stacks. forth.
1.1.6. No Architectural Dependency on IPv4 1.5. Compatible with Standard IPv4 and IPv6 Stacks
SIIT-DC will allow an ICP or data centre operator to build Except for the introduction of the BRs themselves, no change to the
infrastructure and applications entirely on IPv6. This means that network, nodes, applications, or anything else is required in order
when the day comes to discontinue support for IPv4, no change needs to support SIIT-DC. SIIT-DC is practically invisible from the point
to be made to the overall architecture - it's only a matter of of view of the IPv4 clients, the IPv6 nodes, the IPv6 data centre
shutting off the SIIT-DC Gateways. Therefore, by deploying native network, and the IPv4 Internet. SIIT-DC interoperates with all
IPv6 along with SIIT-DC, operators will avoid future migration or standards-compliant IPv4 or IPv6 stacks.
deployment projects relating to IPv6 roll-out and/or IPv4 sun-
setting.
2. Terminology 2. Terminology
This document makes use of the following terms: This document makes use of the following terms:
IPv4 Service Address A public IPv4 address with which IPv4-only SIIT-DC Border Relay (BR)
clients will communicate. This communication will be translated A device or a logical function that performs stateless protocol
to IPv6 by the SIIT-DC Gateway. translation between IPv4 and IPv6 in accordance with [RFC6145] and
[I-D.ietf-v6ops-siit-eam].
IPv4 Service Address Pool One or more IPv4 prefixes routed to the SIIT-DC Edge Relay (ER)
SIIT-DC Gateway's IPv4 interface. IPv4 Service Addresses are A device or logical function that provides "native" IPv4
allocated from this pool. Note that this does not necessarily connectivity to IPv4-only devices or application software. It is
have to be a "pool" per se, as it could also be one or more host very similar in function to a BR, but is typically located close
routes (whose prefix length is equal to /32). The primary purpose to the IPv4-only component(s) it is supporting rather than on the
of using a pool rather than host routes is to facilitate IPv4 IDC's outer network border. The ERs is an optional component of
route aggregation and ease provisioning of new IPv4 Service SIIT-DC. It is discussed in more detail in
Addresses. [I-D.ietf-v6ops-siit-dc-2xlat].
IPv6 Service Address A public IPv6 address assigned to a server or IPv4 Service Address
application in the IPv6 network. IPv6-only and dual stacked A public IPv4 address with which IPv4-only clients communicates.
clients communicates with this address directly without invoking This communication will be translated to IPv6 by a BR. The
SIIT-DC. IPv4-only clients also communicates with this address service's "IN A" DNS record will typically point to the IPv4
through the SIIT-DC Gateway and via an IPv4 Service Address. Service Address.
SIIT-DC Host Agent A logical function very similar to an SIIT-DC IPv4 Service Address Pool
Gateway that resides on a server and provides virtual IPv4 One or more IPv4 prefixes routed to the BR's IPv4 interface. IPv4
connectivity to applications, by reversing the translations done Service Addresses are allocated from this pool. That this does
by the SIIT-DC Gateway. It is an optional component of the SIIT- not necessarily have to be a "pool" per se, as it could also be
DC architecture, that may be used to increase application support. one or more host routes (whose prefix length is equal to /32).
See [I-D.anderson-v6ops-siit-dc-2xlat]. The purpose of using a pool rather than host routes is to
facilitate IPv4 route aggregation and ease provisioning of new
IPv4 Service Addresses.
SIIT-DC Gateway A device or a logical function that translates IPv6 Service Address
between IPv4 and IPv6 in accordance with Section 5. A public IPv6 address assigned to a node (such as a server or
load-balancer) or an individual application in the IPv6 network.
IPv6-capable clients communicate directly with the IPv6 Service
Address using native IPv6. The service's "IN AAAA" DNS record
will typically point to the IPv6 Service Address. IPv4-only
clients indirectly communicate with the IPv6 Service Address
through SIIT-DC.
Static Address Mapping A bi-directional mapping between an IPv4 Explicit Address Mapping (EAM)
Service Address and an IPv6 Service Address configured in the A bi-directional coupling between an IPv4 Service Address and an
SIIT-DC Gateway. When translating between IPv4 and IPv6, the IPv6 Service Address configured in a BR or ER. When translating
SIIT-DC Gateway changes the address fields in the translated between IPv4 and IPv6, the BR/ER changes the address fields in the
packet's IP header according to any matching Static Address translated packet's IP header according to any matching EAM. See
Mapping. [I-D.ietf-v6ops-siit-eam].
Translation Prefix An IPv6 prefix into which the entire IPv4 address Translation Prefix
space is mapped. This prefix is routed to the SIIT-DC Gateway's An IPv6 prefix into which the entire IPv4 address space is mapped.
IPv6 interface. It is either an Network-Specific Prefix or a This prefix is routed to the BR's IPv6 interface. It is either a
Well-Known Prefix as specified in [RFC6052]. When translating Network-Specific Prefix or the Well-Known Prefix 64:ff9b::/96, cf.
between IPv4 and IPv6, the SIIT-DC Gateway prepends or strips the [RFC6052]. When translating between IPv4 and IPv6, a BR/ER
Translation Prefix from the address fields in the translated inserts or removes the Translation Prefix from the address fields
packet's IP header, unless a Static Address Mapping exists for the in the translated packet's IP header, unless an EAM for the IP
IP address in question. address being translated exists.
IPv4-translatable IPv6 addresses
As defined in Section 1.3 of [RFC6052].
IDC
Short for "Internet Data Centre"; a data centre whose main purpose
is to deliver services to the public Internet, the use case SIIT-
DC is primarily targeted at. IDCs are typically operated by
Internet Content Providers or Managed Services Providers.
SIIT
The Stateless IP/ICMP Translation algorithm, as specified in
[RFC6145].
XLAT
Short for "translation".
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].
3. Architectural Overview 3. Architectural Overview
This section describes the basic SIIT-DC architecture. This section describes the basic SIIT-DC architecture.
SIIT-DC Architecture SIIT-DC Architecture
+-------------------+ +----------------+ IPv6-capable user IPv4-only user
| IPv6-capable user | | IPv4-only user | <2001:db8::ab:cd> <203.0.113.50>
| ================= | | ============== | | |
| | | | (the IPv6 internet) (the IPv4 Internet)
+-<2001:db8::ab:cd>-+ +-<203.0.113.50>-+ | |
| | | +-[BR]---------<192.0.2.0/24>--------------+
(the IPv6 internet) (the IPv4 Internet) | | |
| | | | EAM #1: 192.0.2.1,2001:db8:12:34::1 |
| +------------------<192.0.2.0/24>-+ | | EAM #2..#n: [...] |
| | | | | XLAT Prefix: 2001:db8:46::/96 |
| | SIIT-DC Gateway | | | |
| | =============== | | +------------<2001:db8:46::/96>------------+
| | | | |
| | Translation Prefix: | (the IPv6-only data centre network)
| | 2001:db8:46::/96 | |
| | | +--<2001:db8:12:34::1>--[v6-only server]-+
| | Static Address Mapping: | | | |
| | 192.0.2.1 <=> 2001:db8:12:34::1 | | +-[2001:db8:12:34::1]--[v6-only app]-+ |
| | | | | AF_INET6 socket | |
| +--------------<2001:db8:46::/96>-+ | +------------------------------------+ |
| | +----------------------------------------+
(the IPv6-only data centre network)
| |
| ------------------------------/
|/
|
+--<2001:db8:12:34::1>------------------------------+
| | |
| | IPv6-only server |
| | ================ |
| | |
| +-[2001:db8:12:34::1]---------------------------+ |
| | AF_INET6 | |
| | | |
| | IPv6-only application | |
| | | |
| +-----------------------------------------------+ |
+---------------------------------------------------+
Figure 1 Figure 1
In this example, 192.0.2.0/24 is allocated as an IPv4 Service Address In Figure 1, 192.0.2.0/24 is the IPv4 Service Address Pool.
Pool. Individual IPv4 Service Addresses are assigned from this pool. Individual IPv4 Service Addresses are assigned from this prefix, and
The provider must route this prefix to the SIIT-DC Gateway's IPv4 traffic destined for it is routed to the BR's IPv4-facing network
interface. Note that there are no restrictions on how many IPv4 interface. There are no restrictions on how many IPv4 Service
Service Address Pools are used or their prefix length, as long as Address Pools are used or their prefix length, as long as they are
they are all routed to the SIIT-DC Gateway's IPv4 interface. all routed to the BR's IPv4-facing network interface.
The Static Address Mapping list is used when translating an IPv4
Service Address (here 192.0.2.1) to its corresponding IPv6 Service
Address (here 2001:db8:12:34::1) and vice versa. When the SIIT-DC
Gateway translates an IPv4 packet to IPv6, any IPv4 Service Address
found in the original IPv4 header will be replaced with the
corresponding IPv6 Service Address in the resulting IPv6 header, and
vice versa when translating an IPv6 packet to IPv4.
2001:db8:46::/96 is the Translation 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 [RFC6052]. This algorithmic
mapping has a lower precedence than the configured Static Address
Mappings.
The SIIT-DC Gateway itself can be either a separate device or a When translating packets between IPv4 and IPv6, the BR uses the EAM
logical function in another multi-purpose device, for example an IP to replace any occurrence of the IPv4 Service Address (192.0.2.1)
router. Any number of SIIT-DC Gateways may exist simultaneously in with its corresponding IPv6 Service Address (2001:db8:12:34::1).
an operators infrastructure, as long as they all have the same Addresses that do not match any EAM configured in the BR are
translation prefix and list of Static Mappings configured. translated by inserting or removing the Translation Prefix
(2001:db8:46::/96), cf. Section 2.2 of RFC6052 [RFC6052].
3.1. DNS Configuration The BR can be deployed as a separate device or as a logical function
in another multi-purpose device, such as an IP router. Any number of
BRs may exist simultaneously in the IDC's network infrastructure, as
long as they all configured with the same Translation Prefix and an
identical EAM Table.
The IPv6 Service Address of should be registered in DNS using an "IN The IPv6 Service Address of should be registered in DNS using an "IN
AAAA" record, while its corresponding IPv4 Service Address should be AAAA" record, while its corresponding IPv4 Service Address should be
registered using an "IN A" record. This results in the following DNS registered using an "IN A" record. This ensures that IPv6-capable
records: clients access the application/service directly using its native IPv6
end-to-end, while IP4-only clients will access it through SIIT-DC.
DNS Configuration for a SIIT-DC enabled service
www.example.com. IN AAAA 2001:db8:12:34::1
www.example.com. IN A 192.0.2.1
Figure 2
3.2. Packet Flow
In this example, "IPv4-only user" initiates a request to the
application running on the IPv6-only server. He starts by looking up
the "IN A" record of "www.example.org" in DNS, and attempts to
connect to this address on the service by transmitting the following
IPv4 packet destined for the IPv4 Service Address:
Stage 1: Client -> Server, IPv4
+------------------------------------------------+
| IP Version: 4 |
| Source Address: 203.0.113.50 |
| Destination Address: 192.0.2.1 |
| Protocol: TCP |
|------------------------------------------------|
| TCP SYN [...] |
+------------------------------------------------+
Figure 3
This packet is then routed over the Internet to the (nearest) SIIT-DC
Gateway, which translates it into the following IPv6 packet and
forward it into the IPv6 network:
Stage 2: Client -> Server request, IPv4
+-------------------------------------------------+
| IP Version: 6 |
| Source Address: 2001:db8:46::203.0.113.50 |
| Destination Address: 2001:db8:12:34::1 |
| Next Header: TCP |
|-------------------------------------------------|
| TCP SYN [...] |
+-------------------------------------------------+
Figure 4
The destination address field was translated to the IPv6 Service
Address according to the configured Static Address Mapping, while the
source address was field translated according to the [RFC6052]
mapping using the Translation Prefix (because it did not match any
Static Address Mapping). 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::203.0.113.50 may also be 3.1. Packet Flow
expressed as 2001:db8:46::cb00:7132, cf. Section 2.2 of RFC4291
[RFC4291].
Next, the application receives receives this IPv6 packet and responds In this example, the "IPv4-only user" from Figure 1 initiates a
to it like it would with any other IPv6 packet: connection to the application running on the IPv6-only server. After
first having looked up the "IN A" record in DNS, the user starts by
transmitting an TCP SYN packet to the IPv4 Service Address. This
IPv4 packet is routed to the BR, and is there translated to IPv6 as
follows:
Stage 3: Server -> Client response, IPv6 IPv4 to IPv6 translation
+-------------------------------------------------+ +--[IPv4]----------+ +--[IPv6]-----------------------+
| IP Version: 6 | | SRC 203.0.113.50 | | SRC 2001:db8:46::203.0.113.50 |
| Source Address: 2001:db8:12:34::1 | | DST 192.0.2.1 | --> | DST 2001:db8:12:34::1 |
| Destination Address: 2001:db8:46::203.0.113.50 | | TCP SYN [..] | | TCP SYN [..] |
| Next Header: TCP | +------------------+ +-------------------------------+
|-------------------------------------------------|
| TCP SYN+ACK [...] |
+-------------------------------------------------+
Figure 5 Figure 2
The response packet is routed to the (nearest) SIIT-DC Gateway's IPv6 The resulting IPv6 packet is routed to the IPv6-only server, which
interface, which will translate it back to IPv4 as follows: processes and responds to it as if it had been a native IPv6 packet
all along. The server's IPv6 response packet is then routed back to
the BR, where it is translated back to IPv4 as follows:
Stage 4: Server -> Client response, IPv4 IPv6 to IPv4 translation
+------------------------------------------------+ +--[IPv6]-----------------------+ +--[IPv4]----------+
| IP Version: 4 | | SRC 2001:db8:12:34::1 | | SRC 192.0.2.1 |
| Source Address: 192.0.2.2 | | DST 2001:db8:46::203.0.113.50 | --> | DST 203.0.113.50 |
| Destination Address: 203.0.113.50 | | TCP SYN/ACK [..] | | TCP SYN/ACK [..] |
| Protocol: TCP | +-------------------------------+ +------------------+
|------------------------------------------------|
| TCP SYN+ACK [...] |
+------------------------------------------------+
Figure 6 Figure 3
This time, the source address matched the Static Address Mapping and It is important to note that neither the IPv4 client nor the IPv6
was translated accordingly, while the destination address did not, server/application need any special support to participate in SIIT-
and was therefore translated according to [RFC6052] by having the DC. However, the application may optionally be taught to extract the
Translation Prefix stripped. The rest of the packet was translated embedded IPv4 source address from incoming IPv6 packets with source
according to [RFC6145]. addresses within the Translation Prefix. This will allow it to
perform IPv4-specific tasks such as Geo-Location, logging, abuse
handling, and so on.
The resulting IPv4 packet is transmitted back to the end user over 4. Deployment Considerations and Guidelines
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 4.1. Application/Device Support for IPv6
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.
4. Deployment Guidelines SIIT-DC as described in this document requires that the application
In this section, we list recommendations and guidelines for operators (and/or the node the application is located on) supports IPv6
who would like to deploy a SIIT-DC service in their data centre networking, and that it has no dependency on local IPv4 network
network. connectivity. However, SIIT-DC supports IPv4-dependent applications
and nodes through the introduction of an ER. The ER provides the
application or node with seemingly native IPv4 connectivity, by
translating the packets (that were previously translated from IPv4 to
IPv6) by the BR back to IPv4 before passing them to the
IPv4-dependent application or node. This approach is described in
more detail in [I-D.ietf-v6ops-siit-dc-2xlat].
4.1. Application Support for NAT 4.2. Application Support for NAT
Not all application protocols are able to operate in a network The operator should carefully examine whether or not the application
environment where rewriting of IP addresses occur. An operator protocols he would like to use SIIT-DC with are able to operate in a
should therefore carefully evaluate the applications he would like to network environment where rewriting of IP addresses occur. In
make available for IPv4 users through SIIT-DC, to ensure they do not general, if an application layer protocol works correctly through
fall in this category. In general, if an application layer protocol standard NAT44 (see [RFC3235]), it will most likely work correctly
works correctly through standard NAT44 (see [RFC3235]), it will most through SIIT-DC as well.
likely work correctly through SIIT-DC as well.
Higher-level protocols that embed IP addresses as part of their Higher-level protocols that embed IP addresses as part of their
payload are especially problematic, as noted in [RFC2663], [RFC2993], payload are particularly problematic [RFC2663] [RFC2993] [RFC3022].
and [RFC3022]. Such protocols will most likely not work through any One well-known example of such a protocol is FTP [RFC0959]. Such
form of address translation, including SIIT-DC. One well-known protocols can be made to work with SIIT-DC through the introduction
example of such a protocol is FTP [RFC0959]. of an ER, which provides end-to-end IPv4 address transparency by
reversing the translations performed by the BR before passing the
The SIIT-DC architecture may be extended with a Host Agent that packets to the NAT-incompatible application. This approach is
reverses the translation performed by the SIIT-DC Gateway before described in more detail in [I-D.ietf-v6ops-siit-dc-2xlat].
passing the packets to the application software. This allows the
problematic application protocols described above to work correctly
in an SIIT-DC environment as well. See
[I-D.anderson-v6ops-siit-dc-2xlat] for a description of this
extension.
4.2. Application Support for IPv6
SIIT-DC requires that the application software supports IPv6
networking, and that it has no dependency on IPv4 networking. If
this is not the case, the approach described in
[I-D.anderson-v6ops-siit-dc-2xlat] may be used, as it provides the
application with seemingly native IPv4 connectivity. This allows
IPv4-only applications to work correctly in an otherwise IPv6-only
environment.
4.3. Application Communication Pattern 4.3. Application Communication Pattern
SIIT-DC is ideally suited for applications where IPv4-only nodes on SIIT-DC is best suited for traditional client/server applications
the Internet initiate traffic towards the IPv6-only services, which where IPv4-only clients on the Internet initiate traffic towards an
in turn are only passively listening for inbound traffic and IPv6-only service, which in turn is passively listening for inbound
responding as necessary. One well-known example of such a protocol traffic and responding as necessary. In this case, an IPv4 client
is HTTP [RFC7230]. This is due to the fact that in this case, an looks exactly like an native IPv6 client from the IPv6 service's
IPv4 user looks exactly like an ordinary IPv6 user from the host and point of view, and thus does not require any special treatment. One
application's point of view, and requires no special treatment. particularly common application protocol that follows this client/
server communication pattern, and thus is ideally suited for use with
SIIT-DC, is HTTP [RFC7230].
It is possible to combine SIIT-DC with DNS64 [RFC6147] in order to It is also possible to combine SIIT-DC with DNS64 [RFC6147] in order
allow an IPv6-only application to initiate communication with to allow an IPv6-only application to initiate communication with
IPv4-only nodes through an SIIT-DC Gateway. However, in this case, IPv4-only nodes through SIIT-DC. However, in this case, care must be
care must be taken so that all outgoing communication is sourced from taken so that all outgoing communication is sourced from an IPv6
the IPv6 Service Address that has a Static Mapping configured on the Service Address that is found in an EAM configured in the BR. If
SIIT-DC Gateway. If another unmapped address is used, the SIIT-DC another address is used, the BR will most likely be unable to
Gateway will discard the packet. translate it to IPv4, causing the packet to be discarded. This could
be prevented by altering the Default Address Selection Policy Table
[RFC6724] on the IPv6 node.
An alternative approach to the above would be to make use of an SIIT- An alternative approach to the above would be to place an ER in front
DC Host Agent as described in [I-D.anderson-v6ops-siit-dc-2xlat]. of the application in question, as described
This provides the application with seemingly native IPv4 [I-D.ietf-v6ops-siit-dc-2xlat]. This provides the application with
connectivity, which it may use for both inbound and outbound seemingly native IPv4 connectivity, which it may use freely for bi-
communication without requiring the application to select a specific directional communication with the IPv4 Internet. An application or
source address for its outbound communications. node located behind an ER does not need to worry about selecting a
specific source address, as it will only have valid options
available.
4.4. Choice of Translation Prefix 4.4. Choice of Translation Prefix
Either a Network-Specific Prefix (NSP) from the provider's own IPv6 Either a Network-Specific Prefix (NSP) from the provider's own IPv6
address space or the IANA-allocated Well-Known Prefix 64:ff9b::/96 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 (WKP) may be used. From a technical point of view, both work equally
equally well, however as only a single WKP exists, if a provider well. However, only a single WKP exists, so if a provider would like
would like to deploy more than one instance of SIIT-DC in his to deploy more than one instance of SIIT-DC in his network, or
network, or Stateful NAT64 [RFC6146], an NSP must be used anyway for another translation technology such as Stateful NAT64 [RFC6146], the
all but one of those deployments. operator will be forced to use an NSP 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 provide SIIT-DC
service to other operators across Autonomous System borders.
For these reasons, this document recommends that an NSP is used. Another consideration is that the WKP cannot be used in inter-domain
Section 3.3 of [RFC6052] discusses the choice of translation prefix routing. By using an NSP instead, SIIT-DC will support a deployment
in more detail. where the BR and the IPv6 Service Address are located in different
Autonomous Systems.
The Translation Prefix may use any of the lengths described in The Translation Prefix may use any of the lengths described in
Section 2.2 of RFC6052 [RFC6052], but /96 has two distinct advantages Section 2.2 of RFC6052 [RFC6052], but /96 has two distinct advantages
over the others. First, converting it to IPv4 can be done in a over the others. First, converting it to IPv4 can be done in a
single operation by simply stripping off the first 96 bits; second, single operation by simply stripping off the first 96 bits; second,
it allows for IPv4 addresses to be embedded directly into the text it allows for IPv4 addresses to be embedded directly into the text
representation of an IPv6 address using the familiar dotted quad representation of an IPv6 address using the familiar dotted quad
notation, e.g., "2001:db8::198.51.100.10" (cf. Section 2.4 of RFC6052 notation, e.g., "2001:db8::198.51.100.10" (cf. Section 2.4 of RFC6052
[RFC6052])), instead of being converted to hexadecimal notation. [RFC6052])), instead of being converted to hexadecimal notation.
This makes it easier to write IPv6 ACLs and similar that match This makes it easier to write IPv6 ACLs and similar that match
translated endpoints in the IPv4 Internet. Use of a /96 prefix translated endpoints in the IPv4 Internet.
length is therefore recommended.
For the reasons discussed above, this document recommends that an NSP
with a prefix length of /96 is used. Section 3.3 of [RFC6052]
discusses the choice of translation prefix in more detail.
4.5. Routing Considerations 4.5. Routing Considerations
The prefixes that constitute the IPv4 Service Address Pool and the
IPv6 Translation Prefix may be routed to the SIIT-DC Gateway(s) as
any other IPv4 or IPv6 route in the provider's network.
If more than one SIIT-DC Gateway is being deployed, it is recommended The prefixes that constitute the IPv4 Service Address Pool and the
that a dynamic routing protocol (such as BGP, IS-IS, or OSPF) is IPv6 Translation Prefix may be routed to the BRs as any other IPv4 or
being used to advertise the routes within the provider's network. IPv6 route in the provider's network. If more than one BR is being
This will ensure that the traffic that is to be translated will reach deployed, it is recommended that a routing protocol (IGP) used to
the closest SIIT-DC Gateway, reducing or eliminating sub-optimal advertise the routes within the provider's network. This will ensure
traffic patterns, as well as provide high availability - if one SIIT- that the traffic that is to be translated will reach the closest BR,
DC Gateway fails, the dynamic routing protocol will automatically reducing or eliminating sub-optimal traffic patterns, as well as
redirect the traffic to the next-best translator. providing high availability: Should one BR fail, the IGP will
automatically redirect the traffic to the closest alternate BR.
4.6. Location of the SIIT-DC Gateways 4.6. Location of the SIIT-DC Border Relays
The goal of SIIT-DC is to facilitate a true IPv6-only application and The goal of SIIT-DC is to facilitate a true IPv6-only application and
network architecture, with the sole exception being the IPv4 network architecture, with the sole exception being the IPv4
interfaces of the SIIT-DC Gateways and the network infrastructure interfaces of the BRs and the network infrastructure required to
required to connect them to the IPv4 Internet. Therefore, the SIIT- connect the BRs to the IPv4 Internet. Therefore, the BRs must be
DC Gateways should be located somewhere between the IPv4 Internet and located somewhere between the IPv4 Internet and the application
the application delivery stack. This should be understood to include delivery stack. This should be understood to include all servers,
all servers, load balancers, firewalls, intrusion detection systems, load balancers, firewalls, intrusion detection systems, and similar
and similar devices that are processing traffic to a greater extent devices that are processing traffic to a greater extent than merely
than merely forwarding it. forwarding it.
It is optimal to place the SIIT-DC Gateways as close as possible to It is optimal to place the BRs as close as possible to the direct
the direct path between the servers and the end users. If the path between the location of the IPv6 Service Address and the end
closest translator is located a long way from the optimal path, all users. If the closest BR was located a long way from the direct
packets in both directions must make a detour. This would increase path, all packets in both directions must make a detour in order to
the RTT between the server and the end user by by two times the extra traverse the BR. This would increase the RTT between the service and
latency incurred by the detour, as well as cause unnecessary load on the end user by by two times the extra latency incurred by the
the network links on the detour path. detour, as well as cause unnecessary load on the network links on the
detour path.
Where possible, it is beneficial to implement the SIIT-DC Gateways as Where possible, it is beneficial to implement the BRs as a logical
a logical function within the routers would have handled the traffic function within the routers would have handled the traffic anyway,
anyway, had the topology been dual stacked. This way, the had the topology been dual stacked. This way, a SIIT-DC deployment
translation service would not need to be assigned separate networks does not require separate networks ports (which might become
ports (which might become saturated and impact the service quality), saturated and impact the service quality), nor will it require extra
nor would it require extra rack space and energy. Some particularly rack space and energy. Some particularly good choices of the
good choices of the location could be within a data centre's access location could be within an IDC's access routers, or within the
routers, or within the provider's border routers. When every single Autonomous System's border routers.
application in the data centre or the provider's network eventually
runs on single-stack IPv6, there would no need to run IPv4 on the
inside of the SIIT-DC Gateway. This reduces complexity, and allows
the operator to reclaim IPv4 addresses from the network
infrastructure that may instead be used as IPv4 Service Address
Pools.
Finally, another possibility is that the data centre operator Finally, another possibility is that the IDC operator outsources the
outsources the SIIT-DC service to another entity, for example his SIIT-DC service to another entity, for example his upstream ISP.
upstream ISP. Doing so allows the data centre operator to build a Doing so allows the IDC operator to build a true IPv6-only
true IPv6-only infrastructure. However, in this case, care must be infrastructure.
taken to ensure that the path between the data centre and the SIIT-DC
operator has a stable and known MTU, and that the SIIT-DC Gateways
are not too far away from the data centre (otherwise, translated
traffic could incur a latency penalty).
4.7. Migration from Dual Stack 4.7. Migration from Dual Stack
While this document discusses the use of IPv6-only servers and While this document mainly discusses the use of IPv6-only nodes and
applications, there is no technical requirement that the servers are applications, it is important to note that SIIT-DC is fully
IPv4 free. SIIT-DC works equally well for dual stacked servers, compatible with dual stack infrastructures, including dual stack
which makes migration easy - after setting up the translation nodes and applications.
function, the DNS "IN 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.
It is also possible to use DNS Round Robin to gradually migrate a Thus, migrating a dual-stacked service to an IPv6-only one where
dual-stacked service's IPv4 traffic from native to SIIT-DC. This is SIIT-DC provides the IPv4 Internet connectivity is easy. The
done by configuring multiple DNS "IN A" records for the service's operator would start out by designating the service's current native
hostname, and pointing one portion of them to the service's native IPv6 address as the IPv6 Service Address, and assign it a
IPv4 addresses and another portion to IPv4 Service Addresses handled corresponding IPv4 Service Address. At this point, the service will
by SIIT-DC. The distribution of "IN A" records determines how much respond on both its old (native) IPv4 address, and the SIIT-DC IPv4
of the client traffic will pass through the SIIT-DC Gateway and how Service Address. The operator may now move traffic from the former
much will remain native. This operator may then gradually increase to the latter by changing the service's "IN A" DNS record. Once all
the share of SIIT-DC "IN A" DNS records until no native addresses IPv4 traffic has been successfully moved to SIIT-DC, the old IPv4
remain. address may be reclaimed.
When all client traffic is handled by SIIT-DC, the operator may 4.8. Translation of ICMPv6 Errors to IPv4
proceed to remove the (now unused) IPv4 addresses assigned to the
servers in question. They could then potentially be recycled as
another IPv4 Service Address Pool assigned to SIIT-DC.
4.8. Packet Size and Fragmentation Considerations In response to an IPv4 packet subsequently translated to IPv6 by the
BR, an IPv6 router in the IDC network may need to transmit an ICMPv6
error back to the origin IPv4 node. By default, such an ICMPv6 error
will most likely be discarded by the BR, unless the source address of
the ICMPv6 error happens to be a IPv4-translatable IPv6 address or
covered by an EAM.
To facilitate reliable delivery of such ICMPv6 errors, an SIIT-DC
operator SHOULD implement the recommendations in [RFC6791] in the
BRs.
4.9. MTU and Fragmentation
There are some key differences between IPv4 and IPv6 relating to There are some key differences between IPv4 and IPv6 relating to
packet sizes and fragmentation that one should consider when packet sizes and fragmentation that one should consider when
deploying SIIT-DC. They result in a few problematic corner cases, deploying SIIT-DC. They result in a few problematic corner cases,
which can be dealt with in a few different ways. The following which can be dealt with in a few different ways. The following
subsections will discuss these in detail, and provide operational subsections will discuss these in detail, and provide operational
guidance. guidance.
In particular, the operator may find that relying on fragmentation in In particular, the operator may find that relying on fragmentation in
the IPv6 domain is undesired or even operationally impossible the IPv6 domain is undesired or even operationally impossible
skipping to change at page 16, line 4 skipping to change at page 13, line 47
There are some key differences between IPv4 and IPv6 relating to There are some key differences between IPv4 and IPv6 relating to
packet sizes and fragmentation that one should consider when packet sizes and fragmentation that one should consider when
deploying SIIT-DC. They result in a few problematic corner cases, deploying SIIT-DC. They result in a few problematic corner cases,
which can be dealt with in a few different ways. The following which can be dealt with in a few different ways. The following
subsections will discuss these in detail, and provide operational subsections will discuss these in detail, and provide operational
guidance. guidance.
In particular, the operator may find that relying on fragmentation in In particular, the operator may find that relying on fragmentation in
the IPv6 domain is undesired or even operationally impossible the IPv6 domain is undesired or even operationally impossible
[I-D.taylor-v6ops-fragdrop]. For this reason, the recommendations in [I-D.taylor-v6ops-fragdrop]. For this reason, the recommendations in
this section seeks to minimise the use of IPv6 fragmentation. this section seeks to minimise the use of IPv6 fragmentation.
Unless otherwise stated, the following subsections assume that the Unless otherwise stated, the following subsections assume that the
MTU in both the IPv4 and IPv6 domains is 1500 bytes. MTU in both the IPv4 and IPv6 domains is 1500 bytes.
4.8.1. IPv4/IPv6 Header Size Difference 4.9.1. IPv4/IPv6 Header Size Difference
The IPv6 header is up to 20 bytes larger than the IPv4 header. This 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 means that a full-size 1500 bytes large IPv4 packet cannot be
translated to IPv6 without being fragmented, otherwise it would translated to IPv6 without being fragmented, otherwise it would
likely have resulted in a 1520 bytes large IPv6 packet. likely have resulted in a 1520 bytes large IPv6 packet.
If the transport protocol used is TCP, this is generally not a 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. problem, the IPv6 node will advertise a TCP MSS of 1440 bytes during
This causes the client to never send larger packets than what can be the initial TCP handshake. This causes the IPv4 clients to never
translated to a single full-size IPv6 packet, eliminating any need send larger packets than what can be translated to a single full-size
for fragmentation. IPv6 packet, eliminating any need for fragmentation.
For other transport protocols, full-size IPv4 packets with the DF For other transport protocols, full-size IPv4 packets with the DF
flag cleared will need to be fragmented by the SIIT-DC Gateway. The flag cleared will need to be fragmented by the BR. This may be
only way to avoid this is to increase the Path MTU between the SIIT- avoided by increasing the Path MTU between the BR and the IPv6 nodes
DC Gateway and the servers to 1520 bytes. Note that the servers' MTU to 1520 bytes or greater. If this is done, the MTU on the IPv6 nodes
SHOULD NOT be increased accordingly, as that would cause them to themselves SHOULD NOT be increased accordingly, as doing so would
undergo Path MTU Discovery for most native IPv6 destinations. cause them to undergo Path MTU Discovery for all destinations on the
However, the servers would need to be able to accept and process IPv6 Internet. The nodes MUST however be able to accept and process
incoming packets larger than their own MTU. If the server's IPv6 incoming packets larger than their own MTU. If the nodes' IPv6
implementation allows the MTU to be set differently for specific implementation allows the initial Path MTU to be set differently for
destinations, it could be increased to 1520 for destinations within specific destinations, it MAY be increased to 1520 for destinations
the Translation Prefix specifically. within the Translation Prefix specifically.
4.8.2. IPv6 Atomic Fragments 4.9.2. IPv6 Atomic Fragments
In keeping with the fifth paragraph of Section 4 of RFC6145 In keeping with the fifth paragraph of Section 4 of RFC6145
[RFC6145], an SIIT-DC Gateway will by default add an IPv6 [RFC6145], a stateless translator like a BR will by default add an
Fragmentation header to the resulting IPv6 packet when translating an IPv6 Fragmentation header to the resulting IPv6 packet when
IPv4 packet with the Don't Fragment flag set to 0. translating an IPv4 packet with the Don't Fragment flag set to 0.
This happens even though the resulting IPv6 packet isn't actually This happens even though the resulting IPv6 packet isn't actually
fragmented into several pieces, resulting in an IPv6 Atomic Fragment fragmented into several pieces, resulting in an IPv6 Atomic Fragment
[RFC6946]. These Atomic Fragments are generally not useful in a data [RFC6946]. These Atomic Fragments are generally not useful in an IDC
centre environment, and it is therefore recommended that this environment, and it is therefore recommended that this behaviour is
behaviour is disabled in the SIIT-DC Gateways. To this end, disabled in the BRs. To this end, Section 4 of RFC6145 [RFC6145]
Section 4 of RFC6145 [RFC6145] notes that the "translator MAY provide notes that the "translator MAY provide a configuration function that
a configuration function that allows the translator not to include allows the translator not to include the Fragment Header for the non-
the Fragment Header for the non-fragmented IPv6 packets". fragmented IPv6 packets".
Note that [I-D.ietf-6man-deprecate-atomfrag-generation] seeks to Note that [I-D.ietf-6man-deprecate-atomfrag-generation] seeks to
update [RFC6145], making the functionality described above as the update [RFC6145], making the functionality described above as the
standard and only mode of operation. standard and only mode of operation.
In IPv6, the Identification value is located inside the Fragmentation In IPv6, the Identification value is located inside the Fragmentation
header. That means that if the generation of IPv6 Atomic Fragments header. That means that if the generation of IPv6 Atomic Fragments
is disabled, the IPv4 Identification value will be lost during is disabled, the IPv4 Identification value will be lost during
translation to IPv6. This could potentially confuse some diagnostic translation to IPv6. This could potentially confuse some diagnostic
tools. tools.
4.8.3. Minimum Path MTU Difference Between IPv4 and IPv6 4.9.3. Minimum Path MTU Difference Between IPv4 and IPv6
Section 5 of RFC2460 [RFC2460] specifies that the minimum IPv6 link Section 5 of RFC2460 [RFC2460] specifies that the minimum IPv6 link
MTU is 1280 bytes. Therefore, an IPv6 node can reasonably assume MTU is 1280 bytes. Therefore, an IPv6 node can reasonably assume
that if it transmits an IPv6 packet that is 1280 bytes or smaller, it that if it transmits an IPv6 packet that is 1280 bytes or smaller, it
is guaranteed to reach its destination without requiring is guaranteed to reach its destination without requiring
fragmentation or invoking the Path MTU Discovery algorithm [RFC1981]. fragmentation or invoking the Path MTU Discovery algorithm [RFC1981].
However, this assumption fails if the destination is an IPv4 node However, this assumption might prove false if the destination is an
reached through a protocol translator such as an SIIT-DC Gateway, as IPv4 node reached through a protocol translator such as a BR, as the
the minimum IPv4 link MTU is 68 bytes. See Section 3.2 of RFC791 minimum IPv4 link MTU is 68 bytes. See Section 3.2 of RFC791
[RFC0791]. [RFC0791].
Section 5.1 of RFC6145 [RFC6145] specifies that an SIIT-DC Gateway Section 5.1 of RFC6145 [RFC6145] specifies that a stateless
should set the IPv4 Don't Fragment flag to 1 when it translates a translator should set the IPv4 Don't Fragment flag to 1 when it
non-fragmented IPv6 packet to IPv4. This means that when the path to translates a non-fragmented IPv6 packet to IPv4. This means that
the destination IPv4 node contains an IPv4 link with an MTU smaller when the path to the destination IPv4 node contains an IPv4 link with
than 1260 bytes (which corresponds to an IPv6 MTU smaller than 1280 an MTU smaller than 1260 bytes (which corresponds to an IPv6 MTU
bytes, cf. Section 4.8.1), the Path MTU Discovery algorithm will be smaller than 1280 bytes, cf. Section 4.9.1), the Path MTU Discovery
invoked, even if the original IPv6 packet was only 1280 bytes large. algorithm will be invoked, even if the original IPv6 packet was only
This happens as a result of the IPv4 router connecting to the IPv4 1280 bytes large. This happens as a result of the IPv4 router
link with the small MTU returning an ICMPv4 Need To Fragment error connecting to the IPv4 link with the small MTU returning an ICMPv4
with an MTU value smaller than 1260, which in turns is translated by Need To Fragment error with an MTU value smaller than 1260, which in
the SIIT-DC Gateway to an ICMPv6 Packet Too Big error with an MTU turns is translated by the BR to an ICMPv6 Packet Too Big error with
value smaller than 1280 which is then transmitted to the origin IPv6 an MTU value smaller than 1280 which is then transmitted to the
node. origin IPv6 node.
When an IPv6 node receives an ICMPv6 Packet Too Big error indicating When an IPv6 node receives an ICMPv6 Packet Too Big error indicating
an MTU value smaller than 1280, the last paragraph of Section 5 of an MTU value smaller than 1280, the last paragraph of Section 5 of
RFC2460 [RFC2460] gives it two choices on how to proceed: RFC2460 [RFC2460] gives it two choices on how to proceed:
o It may reduce its Path MTU value to the value indicated in the o It may reduce its Path MTU value to the value indicated in the
Packet Too Big, i.e., limit the size of subsequent packets Packet Too Big, i.e., limit the size of subsequent packets
transmitted to that destination to the indicated value. This transmitted to that destination to the indicated value. This
approach causes no problems for the SIIT-DC function, as it simply approach causes no problems for the SIIT-DC function, as it simply
allows Path MTU Discovery to work transparently across the SIIT-DC allows Path MTU Discovery to work transparently across the BR.
Gateway.
o It may reduce its Path MTU value to exactly 1280, and in addition o It may reduce its Path MTU value to exactly 1280, and in addition
include a Fragmentation header in subsequent packets sent to that include a Fragmentation header in subsequent packets sent to that
destination. In other words, the IPv6 node will start emitting destination. In other words, the IPv6 node will start emitting
Atomic Fragments. The Fragmentation header signals to the the Atomic Fragments. The Fragmentation header signals to the the BR
SIIT-DC Gateway that the Don't Fragment flag should be set to 0 in that the Don't Fragment flag should be set to 0 in the resulting
the resulting IPv4 packet, and it also provides the Identification IPv4 packet, and it also provides the Identification value.
value.
If the use of the IPv6 Fragmentation header is problematic, and the If the use of the IPv6 Fragmentation header is problematic, and the
operator has IPv6 nodes that implement the second option above, the operator has IPv6 nodes that implement the second option above, the
operator should consider enabling the functionality described as the operator should consider enabling the functionality described as the
"second approach" in Section 6 of RFC6145 [RFC6145]. This "second approach" in Section 6 of RFC6145 [RFC6145]. This
functionality changes the SIIT-DC Gateway's behaviour as follows: functionality changes the BR's behaviour as follows:
o When translating ICMPv4 Need To Fragment to ICMPv6 Packet Too Big, o When translating ICMPv4 Need To Fragment to ICMPv6 Packet Too Big,
the resulting packet will never contain an MTU value lower than the resulting packet will never contain an MTU value lower than
1280. This prevents the IPv6 nodes from generating Atomic 1280. This prevents the IPv6 nodes from generating Atomic
Fragments. Fragments.
o When translating IPv6 packets smaller than or equal to 1280 bytes, o When translating IPv6 packets smaller than or equal to 1280 bytes,
the Don't Fragment flag in the resulting IPv4 packet will be set the Don't Fragment flag in the resulting IPv4 packet will be set
to 0. This ensures that in the eventuality that the path contains to 0. This ensures that in the eventuality that the path contains
an IPv4 link with an MTU smaller than 1260, the IPv4 router an IPv4 link with an MTU smaller than 1260, the IPv4 router
skipping to change at page 18, line 40 skipping to change at page 16, line 32
In summary, this approach could be seen as prompting the IPv4 In summary, this approach could be seen as prompting the IPv4
protocol itself to provide the "link-specific fragmentation and protocol itself to provide the "link-specific fragmentation and
reassembly at a layer below IPv6" required for links that "cannot reassembly at a layer below IPv6" required for links that "cannot
convey a 1280-octet packet in one piece", to paraphrase Section 5 of convey a 1280-octet packet in one piece", to paraphrase Section 5 of
RFC2460 [RFC2460]. Note that RFC2460 [RFC2460]. Note that
[I-D.ietf-6man-deprecate-atomfrag-generation] seeks to update [I-D.ietf-6man-deprecate-atomfrag-generation] seeks to update
[RFC6145], making the approach described above as the standard and [RFC6145], making the approach described above as the standard and
only mode of operation. only mode of operation.
5. Implementation Requirements 4.10. IPv4-translatable IPv6 Service Addresses
This normative section specifies the SIIT-DC protocol that is
implemented by an SIIT-DC Gateway. Because SIIT-DC builds on and
closely resembles SIIT [RFC6145], this section should be read as a
set of additions and changes that are applied to an implementation
already compliant to SIIT [RFC6145]. Each of the following
subsections discuss how the requirement relates to with any
corresponding requirements in SIIT [RFC6145].
5.1. Compliance with RFC6145 and RFC6052
Unless otherwise stated in the following sections, an SIIT-DC
implementation MUST comply fully with [RFC6145]. It must also
implement the algorithmic address mapping defined in [RFC6052].
5.2. Static Address Mapping Function
The implementation MUST allow the operator to configure an arbitrary
number of Static Address 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 Address Mapping would be:
o 192.0.2.1 <=> 2001:db8:12:34::1
To accomplish the same using unidirectional mappings, the following
two mappings must instead be configured:
o 192.0.2.1 => 2001:db8:12:34::1
o 2001:db8:12:34::1 => 192.0.2.1
In both cases, if the SIIT-DC Gateway receives an IPv6 packet that
has the value 2001:db8:12:34::1 in either the source or destination
field of the IPv6 header, it MUST rewrite this field to 192 0.2.1
when translating to IPv4. Similarly, if the SIIT-DC Gateway receives
an IPv4 packet that has the value 192.0.2.1 as the either the source
or destination field of the IPv4 header, it MUST rewrite this field
to 2001:db8:12:34::1 when translating to IPv6. For all IPv4 or IPv6
source or destination field values for which there are no matching
Static Address Mapping, [RFC6052] compliant mapping MUST be used
instead.
Relation to [RFC6145]: The Static Address Mapping is a novel feature
feature that is not discussed in [RFC6145]. It conflicts with the
[RFC6145] requirement that all addresses must be translated according
to the [RFC6052] algorithm.
5.3. Support for Increasing the IPv6 Path MTU
The SIIT-DC Gateway MUST provide a configuration function for the
network administrator to adjust the threshold of the minimum IPv6 MTU
to a value that reflects the real value of the minimum IPv6 MTU in
the network (greater than 1280 bytes). This will help reduce the
chance of including the Fragment Header in the resulting IPv6
packets.
Relation to [RFC6145]: This strengthens the corresponding "MAY" SIIT-DC is designed so that the IPv6 Service Addresses are not
requirement located in Section 4 of RFC6145 [RFC6145] to a "MUST". required to be IPv4-translatable IPv6 addresses. Section 2 of I-D
.ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam] discusses why it is
desirable to avoid requiring the use of IPv4-translatable IPv6
addresses.
5.4. Loop Prevention Mechanism It is however quite possible to deploy SIIT-DC in combination with
IPv4-translatable IPv6 Service Addresses. The primary benefits in
doing so are:
As noted in Section 9.2, there is a potential for packets looping o The operator is not required to provision EAMs for
through the SIIT-DC function if it receives an IPv4 packet for which IPv4-translatable IPv6 Service Addresses onto the BR/ERs.
there is no Static Address 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-DC function.
If such a mechanism isn't provided, the implementation MUST provide a o [RFC6145] translation can be performed in a checksum-neutral
way to manually filter or null-route the destination addresses that manner, cf. Section 4.1 of RFC6052 [RFC6052].
would otherwise cause loops.
Relation to [RFC6145]: This security consideration applies only when The trade-off is that the IPv4-translatable IPv6 Service Addresses
an SIIT-DC Gateway translates a packet in "pure" SIIT [RFC6145] mode must be configured on the IPv6 nodes, and the applications must be
(i.e., when both address fields are translated according to set up to use them - likely in addition to their primary (non-
[RFC6052]). This consideration is in other words not specific to IPv4-translatable) IPv6 addresses. The IPv4-translatable IPv6
SIIT-DC, it is inherited from [RFC6145]. In spite of this, [RFC6145] Service Addresses must also be routed from the BR through the IDC's
does not describe this consideration or any methods of prevention. IPv6 network infrastructure to the nodes on which they are assigned.
The requirements in this section is therefore novel to SIIT-DC, even This essentially requires the entire IPv6 infrastructure to be made
though they apply equally to [RFC6145]. aware of and handle translated IPv4 traffic as a special case, which
significantly increases complexity. Avoiding such drawbacks is a
design goal of SIIT-DC, cf. Section 1.1, therefore the use of
IPv4-translatable IPv6 Service Addresses is discouraged.
6. Acknowledgements 5. Acknowledgements
The author would like to thank the following individuals for their The author would like to thank the following individuals for their
contributions, suggestions, corrections, and criticisms: Fred Baker, contributions, suggestions, corrections, and criticisms: Fred Baker,
Cameron Byrne, Brian E Carpenter, Ross Chandler, Dagfinn Ilmari Cameron Byrne, Brian E Carpenter, Ross Chandler, Dagfinn Ilmari
Mannsaaker, Lars Olafsen, Stig Sandbeck Mathisen, Knut A. Syed, Mannsaaker, Lars Olafsen, Stig Sandbeck Mathisen, Knut A. Syed,
Andrew Yourtchenko. Andrew Yourtchenko.
7. Requirements Language 6. IANA Considerations
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].
8. IANA Considerations
This draft makes no request of the IANA. The RFC Editor may remove This draft makes no request of the IANA. The RFC Editor may remove
this section prior to publication. this section prior to publication.
9. Security Considerations 7. Security Considerations
9.1. Mistaking the Translation Prefix for a Trusted Network
If a Network-Specific Prefix from the provider's own address space is 7.1. Mistaking the Translation Prefix for a Trusted Network
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 be located 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.
9.2. Packets Looping Through the SIIT-DC Function If a Network-Specific Prefix from the provider's own address space is
chosen for the translation prefix, as recommended in Section 4.4,
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 traffic
from translated IPv4 end users on the Internet might appear to be
originating from the provider's own network. It is therefore
important that the translation prefix is treated the same as the
Internet at large, rather than as a trusted network.
If the SIIT-DC Gateway receives an IPv4 packet destined to an address In order to alleviate this problem, the operator may opt to use a
for which there is no Static Address Mapping, its destination address Translation Prefix that is distinct from and not a subset of the IPv6
will be rewritten according to [RFC6052], making the resulting IPv6 prefixes used elsewhere in the network infrastructure.
packet have a destination address within the translation prefix,
which is likely routed to back to the SIIT-DC 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 8. References
destinations addresses for which there are no Static Address
Mappings, or whose resulting IPv6 address does not have a more-
specific route to the IPv6 network, are immediately discarded.
10. References 8.1. Normative References
10.1. Normative References [I-D.ietf-v6ops-siit-eam]
Anderson, T. and A. Leiva, "Explicit Address Mappings for
Stateless IP/ICMP Translation", draft-ietf-v6ops-siit-
eam-00 (work in progress), May 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
10.2. Informative References [RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G.
Huston, "Stateless Source Address Mapping for ICMPv6
Packets", RFC 6791, November 2012.
[I-D.anderson-v6ops-siit-dc-2xlat] 8.2. Informative References
tore, t., "SIIT-DC: Dual Translation Mode", draft-
anderson-v6ops-siit-dc-2xlat-00 (work in progress),
September 2014.
[I-D.ietf-6man-deprecate-atomfrag-generation] [I-D.ietf-6man-deprecate-atomfrag-generation]
Gont, F., Will, W., and t. tore, "Deprecating the Gont, F., LIU, S., and T. Anderson, "Deprecating the
Generation of IPv6 Atomic Fragments", draft-ietf-6man- Generation of IPv6 Atomic Fragments", draft-ietf-6man-
deprecate-atomfrag-generation-00 (work in progress), deprecate-atomfrag-generation-01 (work in progress), April
November 2014. 2015.
[I-D.ietf-v6ops-siit-dc-2xlat]
Anderson, T., "SIIT-DC: Dual Translation Mode", draft-
ietf-v6ops-siit-dc-2xlat-00 (work in progress), January
2015.
[I-D.taylor-v6ops-fragdrop] [I-D.taylor-v6ops-fragdrop]
Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
M., and T. Taylor, "Why Operators Filter Fragments and M., and T. Taylor, "Why Operators Filter Fragments and
What It Implies", draft-taylor-v6ops-fragdrop-02 (work in What It Implies", draft-taylor-v6ops-fragdrop-02 (work in
progress), December 2013. progress), December 2013.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC 959, October 1985. 9, RFC 959, October 1985.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC Translator (NAT) Terminology and Considerations", RFC
2663, August 1999. 2663, August 1999.
skipping to change at page 23, line 5 skipping to change at page 19, line 21
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January Address Translator (Traditional NAT)", RFC 3022, January
2001. 2001.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002. Application Design Guidelines", RFC 3235, January 2002.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011. Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011. April 2011.
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard,
"IPv6 Support Required for All IP-Capable Nodes", BCP 177, "IPv6 Support Required for All IP-Capable Nodes", BCP 177,
RFC 6540, April 2012. RFC 6540, April 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content Providers and Application Service Providers", RFC Content Providers and Application Service Providers", RFC
6883, March 2013. 6883, March 2013.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
6946, May 2013. 6946, May 2013.
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The
Internet Numbers Registry System", RFC 7020, August 2013.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014. 2014.
[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 Appendix A. Complete SIIT-DC IDC topology example
Deployment Options and Experience", RFC 7269, June 2014.
Appendix A. Complete SIIT-DC topology example
This figure shows a more complete SIIT-DC topology, in order to
better demonstrate the beneficial properties it has. In particular,
it tries to highlight the following:
o Stateless operation: Any number of SIIT-DC Gateways may be
deployed side-by side, or indeed anywhere in the IPv6 network, as
any standard routing mechanism may be used to direct traffic to
them (shown here with BGP on the IPv4 side and ECMP on the IPv6
side). This in turn leads to high availability, should one of the
SIIT-DC Gateways fail or become unavailable, those standard
routing mechanisms will ensure that traffic is automatically
redirect one of the remaining SIIT-DC Gateways.
o IPv4 address conservation: Even though the to customers in the
example have several hundred servers, most of them are not used
for externally available services, and thus do not require an IPv4
address. The network between the servers and the SIIT-DC Gateways
require no IPv4 addresses, either. Furthermore, the IPv4
addresses that are used do not have to be assigned to customers in
the form of aggregated blocks or prefixes; which makes it easy to
achieve 100% effective utilisation of the IPv4 service address
pools.
o Application support: The translation-friendly applications HTTP
and SMTP will work through SIIT-DC without requiring any special
customisation. Furthermore, translation-unfriendly applications
such as FTP will also work if an host agent in present, cf.
[I-D.anderson-v6ops-siit-dc-2xlat].
o Native IPv6 as the foundation: Every server, application, and
network component has access to native and untranslated IPv6
connectivity to each other and to the Internet. Traffic through
the SIIT-DC Gateways will diminish over time as IPv6 is deployed
throughout the Internet. Eventually they may be shut down
entirely, which causes no disruption to the application stacks'
ability to deliver their services over native IPv6.
Example data centre topology using SIIT-DC
/--------------------------------\ /---------------\
| IPv4 Internet | | IPv6 Internet |
\-+----------------------------+-/ \--------+------/
| | |
| <----------[BGP]---------> | |
| | |
+---------<192.0.2.0/24>----------+ +---<192.0.2.0/24>---+ |
| | | | |
| SIIT-DC Gateway 1 | | SIIT-DC Gateway 2 | |
| ================= | | ================= | |
| | | | |
| Translation Prefix: | | | |
| 2001:db8:46::/96 | | | |
| | | | |
| Static Address Mappings: | | Exactly the same | |
| 192.0.2.1 <=> 2001:db8:12:34::1 | | configuration as | |
| 192.0.2.2 <=> 2001:db8:12:34::2 | | SIIT-DC Gateway 1 | |
| 192.0.2.3 <=> 2001:db8:fe:dc::1 | | | |
| 192.0.2.4 <=> 2001:db8:12:34::4 | | | |
| [...] | | | |
| | | | |
+--------<2001:db8:46::/96>-------+ +-<2001:db8:46::/96>-+ |
| | |
| <---------[ECMP]---------> | |
| | |
/-----------------+----------------------------+-\ |
| IPv6 data centre network +----------+
\-+-----------------------------------+----------/
| |
| Customer A's server LAN | Customer B's server LAN
| 2001:db8:12:34::/64 | 2001:db8:fe:dc::/64
| |
| |
+-- www ::1 (IPv6+SIIT-DC) +-- www ::1 (IPv6+SIIT-DC)
| |
| +-- file01 ::f:01 (IPv6)
+-- mta ::2 (IPv6+SIIT-DC) | [...]
| +-- file99 ::f:99 (IPv6)
+-- ftp ::3 (IPv6)
| ::4 (SIIT-DC/Host Agent)
|
+-- app01 ::a:01 (IPv6)
| [...]
+- app99 ::a:99 (IPv6)
|
+-- db01 ::d:01 (IPv6)
| [..]
+-- db99 ::d:99 (IPv6)
Figure 7
Appendix B. Comparison to Other Deployment Approaches
There are a number of alternative deployment strategies a data centre
operator may follow. They each have different properties and helps
solve a different set of challenges. This section aims to compare
the SIIT-DC approach with each of the most common ones, by
highlighting the benefits and disadvantages of each.
B.1. IPv4-only
At the time of writing, IPv4-only operation remains the status quo
for most operators. As such, it is well understood and supported.
An operator can reasonably expect everything to work correctly in an
IPv4-only environment.
Benefits of IPv4-only operation compared to SIIT-DC include:
o No translation occurs, the end-to-end principle is intact.
o Compatible with all common application protocols.
o Compatible with IPv4-only devices.
o Compatible with IPv4-only application software, without requiring
a host agent.
Disadvantages of IPv4-only operation compared to SIIT-DC include:
o Does not provide any form of IPv6 connectivity.
o Does not alleviate IPv4 address scarcity.
B.2. IPv4-only + NAPT44
An operator who would otherwise chose a traditional IPv4-only
approach, but cannot due to having insufficient public IPv4 addresses
available, could chose to deploy using a combination of private IPv4
addresses [RFC1918] and NAPT44 [RFC3022] devices which will translate
between a smaller number of public IPv4 addresses and the private
addresses assigned to the servers that provide public services to the
Internet.
Benefits of IPv4-only + NAPT44 operation compared to SIIT-DC include:
o Compatible with IPv4-only devices.
o Compatible with IPv4-only application software, without requiring
a host agent.
Disadvantages of IPv4-only + NAPT44 operation compared to SIIT-DC
include:
o Does not provide any form of IPv6 availability.
o Requires network devices that track all flow state, which may
create a performance bottleneck and be an easy target for Denial
of Service attacks.
o Limits routing flexibility (prevents closest exit routing), as
outbound traffic must pass across the same NAPT44 device that
handled the inbound traffic.
o Limited potential for horizontal scaling, as packets cannot be
load-balanced across multiple NAT devices.
o Depending on whether or not the NAPT44 device rewrites source
addresses in order to attract the return traffic to itself:
o
* Obscures the true source address of the user from the server/
application, preventing it from e.g. performing geo-location
lookups, or:
* Requires an IPv4 default route to be pointed to the NAPT44
device, also attracting native traffic that does not need to
undergo translation.
In addition, application compatibility is a consideration with both
NAPT44 and SIIT-DC, but the exact nature depends from application to
application, so it is hard to objectively quantify if there is a
clear advantage to either approach here. Some translation-unfriendly
application protocols may work without host modifications through the
use of Application Layer Gateway support in the NAPT44 device (e.g.,
FTP [RFC0959]), or in the SIIT-DC architecture when a host agent is
being used [I-D.anderson-v6ops-siit-dc-2xlat]. Other application
protocols might not work with NAPT44 at all, but will work in the
SIIT-DC if a host agent is being used (e.g., FTP/TLS [RFC4217]).
In summary, the most accurate statement would be to say that an
NAPT44 architecture is more compatible with translation-unfriendly
protocols than plain SIIT-DC, while SIIT-DC is more compatible than
NAPT44 if a host agent is used.
For a more complete discussion of potential issues with running
NAPT44, see Architectural Implications of NAT [RFC2993].
B.3. IPv4-only + NAT64
An operator who would otherwise chose a traditional IPv4-only
approach, but would in addition like to provide service availability
for IPv6 end users, could use Stateful NAT64 [RFC6146] to accomplish
this. In a sense, this would be the mirror image of an SIIT-DC
architecture: The infrastructure and servers remains single-stacked,
while connectivity to the other IP stack is provided through a
translation system. Further information about operating Stateful
NAT64 is found in [RFC7269].
Note that Stateful NAT64 can be deployed with or without NAPT44.
With the exception that IPv6 service availability is being provided,
the discussion in the previous two sections fully applies to an
IPv4-only environment that includes NAT64.
Benefits of IPv4-only + NAT64 operation compared to SIIT-DC include:
o Compatible with IPv4-only devices.
o Compatible with IPv4-only application software, without requiring
a host agent.
Disadvantages of IPv4-only + NAT64 operation compared to SIIT-DC
include:
o Does not alleviate IPv4 address scarcity (assuming NAPT44 isn't
used).
o Requires network devices that track all flow state, which may
create a performance bottleneck and be an easy target for Denial
of Service attacks.
o Limits routing flexibility (prevents closest exit routing), as
outbound traffic must pass across the same NAT64 device that
handled the inbound traffic.
o Limited potential for horizontal scaling, as packets cannot be
load-balanced across multiple NAT devices.
o Obscures the true source address of the user from the server/
application, preventing it from e.g. performing geo-location
lookups.
o The traffic levels on the Stateful NAT64 routers will increase
over time, in lockstep with the increased deployment of IPv6 in
the Internet. For this reason, Section 3.2 of RFC7269 [RFC7269]
notes that the use of Stateful NAT64 in a data centre environment
"is only reasonable at an early stage". With SIIT-DC, the inverse
is true; the traffic levels on the SIIT-DC Gateways will decrease
over time, as end users will prefer to use native IPv6 once it is
available to them.
B.4. Dual Stack
Dual Stack [RFC4213] [RFC6883] could be used both with or without
NAPT44 to handle IPv4. In general, the benefits and disadvantages
are equal to the corresponding IPv4-only option, except for the fact
that Dual Stack does provides IPv6 connectivity. Therefore, his
section only lists the benefits and disadvantages which are unique to
a Dual Stack environment.
Benefits of Dual Stack operation compared to SIIT-DC include:
o No translation occurring, the end-to-end principle is intact
(assuming NAPT44 isn't used).
o Compatible with all common application protocols (assuming NAPT44
isn't used).
o Compatible with IPv4-only devices.
o Compatible with IPv4-only application software, without requiring
a host agent.
Disadvantages of Dual Stack operation compared to SIIT-DC include:
o Does not alleviate IPv4 address scarcity (assuming NAPT44 isn't
used).
o Increases the complexity of the infrastructure, as many things
must done twice (once for IPv4 and once for IPv6). Examples of
things that must be duplicated in this manner under Dual Stack
include: Firewall rules/ACLs, IGP topology, monitoring,
troubleshooting.
o Encourages software developers, systems administrators, etc. to
build architectures that cannot operate correctly without IPv4.
This in turn makes it difficult to make use of Dual Stack as a
short term transitional stage, rather than a near-permanent end
state.
o Increases the amount of things that can encounter failures, and
increases the time required to locate and fix such failures. This
reduces reliability.
B.5. Partial Dual Stack (IPv6-only back-end)
It is possible to use the Dual Stack deployment strategy for front-
end services only. That is, the front-end servers (or load
balancers) that serves public Internet-available services are
provisioned with both native IPv4 and native IPv6 connectivity on
their Internet-facing interfaces, while the interfaces facing the
back-end infrastructure are IPv6 only. All back-end servers that do
not communicate directly with Internet clients are IPv6-only. All
communication between back-end servers as well as all traffic between
the back-end servers and the front-end servers will therefore use
only IPv6.
One variation of this approach is to have a two separate sets of
front-end servers, where one set has IPv4-only Internet-facing
interfaces, while the other set has IPv6-only Internet-facing
interfaces. However, both sets must have IPv6-only interfaces facing
the back-end infrastructure.
Benefits of Partial Dual Stack operation compared to SIIT-DC include:
o No translation occurring, the end-to-end principle is intact. Figure 4 attempts to "tie it all together" and show a more complete
SIIT-DC topology, in order to better demonstrate its advantageous
properties discussed in Section 1. These are discussed in more
detail below.
o Compatible with all common application protocols. Example SIIT-DC IDC topology
o Compatible with IPv4-only devices (front-end only). /--------------------------------\ /---------------\
| IPv4 Internet | | IPv6 Internet |
\-+----------------------------+-/ \--------+------/
| | |
| <----------[BGP]---------> | [BGP]
| | |
+-------<192.0.2.0/24>---------+ +---<192.0.2.0/24>---+ |
| BR #1 | | BR #2 | |
| EAM Table: | | | |
| ========== | | | |
| 192.0.2.1,2001:db8:12:34::1 | | | |
| 192.0.2.2,2001:db8:12:34::2 | | Exactly the same | |
| 192.0.2.3,2001:db8:fe:dc::1 | | configuration as | |
| 192.0.2.4,2001:db8:12:34::4 | | BR #1 has | |
| 192.0.2.5,2001:db8:fe:dc::e | | | |
| | | | |
| XLAT Prefix 2001:db8:46::/96 | | | |
| | | | |
+--------<2001:db8:46::/96>----+ +-<2001:db8:46::/96>-+ |
| | |
| <------[ECMP]------> | |
| | |
/-----------------+----------------------+--\ |
| IPv6 IDC network w/OSPFv3 +------------/
\-+--------------------------------+--------/
| |
| Tenant A's server LAN | Tenant B's server LAN
| 2001:db8:12:34::/64 | 2001:db8:fe:dc::/64
| |
+-- www ::1 (IPv6+SIIT-DC) +-- www-lb ::1 (IPv6+SIIT-DC)
| |
+-- mta ::2 (IPv6+SIIT-DC) +-- web ::80:01 (IPv6-only)
| | [...]
+-- ftp ::3 (IPv6) +-- web ::80:99 (IPv6-only)
| ::4 (IPv4, via ER) |
| | +----+
+-- app01 ::a:01 (IPv6-only) \---- ::e | ER | --\
| [...] +----+ |
+- app99 ::a:99 (IPv6-only) |
| ftp 192.0.2.5 ---/
+-- db01 ::d:01 (IPv6-only)
| [..]
\-- db99 ::d:99 (IPv6-only)
o Compatible with IPv4-only application software (front-end only). Figure 4
Disadvantages of Partial Dual Stack operation compared to SIIT-DC Single Stack IPv6 Operation
include: As discussed in Section 1.1, SIIT-DC facilitates an IPv6-only IDC
network infrastructure. The only places where IPv4 is absolutely
required is between the BRs and the IPv4 Internet, and between any
ERs and the IPv4-only applications or devices they are serving
(illustrated here as the two tenants' FTP servers). The figure
also illustrates how SIIT-DC does not interfere with native IPv6;
when there is no longer a need to support IPv4 clients, the BRs
may be decommissioned without causing any impact to native IPv6
traffic.
o Increases the complexity of the front-end infrastructure, as many Stateless Operation
things must done twice (once for IPv4 and once for IPv6). As discussed in Section 1.2, SIIT-DC operates in a stateless
Examples of things that must be duplicated in this manner under fashion. In the illustration, both BRs are simultaneously
Partial Dual Stack include: Firewall rules/ACLs, IGP topology, advertising (i.e., anycasting) the IPv4 Service Address Pool and
monitoring, troubleshooting. the IPv6 Translation Prefix, so incoming traffic from the IPv4
Internet may arrive at either of the BRs, while outgoing IPv6
traffic destined for IPv4 endpoints are load balanced between them
using Equal-Cost Multipath Routing. No continuous state
synchronisation between the two BRs occurs. Should one of the BRs
fail, the BGP and OSPF protocols will ensure that traffic
converges on the remaining BR. Existing sessions will not be
disrupted, beyond any disruption caused by the BGP/OSPF
convergence process itself.
o Can not support any IPv4-only devices or application software in IPv4 Address Conservation
the back-end infrastructure. As discussed in Section 1.3, SIIT-DC conserves the IDC operator's
IPv4 address space. Even though the two customers in the example
above have several hundred servers, the majority of them are not
used to run services made available directly from the Internet,
and therefore do not need to consume IPv4 addresses. The IDC
network infrastructure consumes no IPv4 addresses, either.
Finally, the IPv4 addresses that are assigned to the SIIT-DC
function as IPv4 Service Address Pools may assigned with 100%
efficiency, one address at a time; there is no requirement to
assign multiple addresses to a single customer in a contiguous
block.
In addition, Partial Dual Stack will alleviate IPv4 address scarcity Application support
compared to the normal Dual Stack approach, but not quite to the same As discussed in Section 1.5, as long as the application protocol
extent as SIIT-DC. This is primarily due to the data centre network is translation-friendly (illustrated here with HTTP and SMTP), it
infrastructure having to be dual-stacked in order to provide native will work with SIIT-DC without requiring any special adaptation.
IPv4 addressing to the front-end servers, and because the front-end Furthermore, translation-unfriendly applications (illustrated here
server LANs must be rounded up in size to the nearest CIDR boundary with FTP) will also work when located behind an ER
which may result in IPv4 addresses being unused. However, depending [I-D.ietf-v6ops-siit-dc-2xlat]. Tenant A's FTP server illustrates
on the exact circumstances, this difference in IPv4 address how an ER may be located in the networking stack of a node, while
consumption between SIIT-DC and Partial Dual Stack may be negligible. Tenant B's FTP server illustrates how the ER may be deployed as a
network service. The latter approach enables SIIT-DC to support
IPv4-only nodes/devices.
Author's Address Author's Address
Tore Anderson Tore Anderson
Redpill Linpro Redpill Linpro
Vitaminveien 1A Vitaminveien 1A
0485 Oslo 0485 Oslo
Norway Norway
Phone: +47 959 31 212 Phone: +47 959 31 212
 End of changes. 119 change blocks. 
1014 lines changed or deleted 620 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/