RFC 7755

SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments

📅 published February 2016, from ietf

SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments 🎀

okay so this is RFC 7755 💖 It's an Informational doc from the IETF (Internet Engineering Task Force), published in February 2016, with ISSN 2070-1721. It was written by T. Anderson from Redpill Linpro. It doesn't obsolete anything and doesn't update anything, since there's no Obsoletes or Updates line in the title block. It's not a standards-track spec, just a "here's how we do it" guide 🧚

Abstract ✨

bestie, the whole point of this doc is describing how to use the Stateless IP/ICMP Translation Algorithm (SIIT) inside an IPv6 Internet Data Center (IDC) 💅 Here's the vibe: legacy IPv4-only clients on the Internet get translated to IPv6 as soon as their traffic hits the IDC operator's network. After that, their traffic gets treated the same as traffic from native IPv6 users 🦋 The IPv6 endpoints can use arbitrary IPv6 addresses that aren't IPv4-translatable, which means you get a single-stack IPv6-only network and you use your public IPv4 addresses super efficiently 🌸

The main audience is IDC operators who are moving to IPv6, running low on IPv4 addresses, and/or who think dual stack is just too much operational drama 😭

Status of This Memo 💜

Real talk, this one is not an Internet Standards Track spec. It's just being published for info 🎀

It's a product of the IETF, so it reflects what the IETF community agreed on. It got public review and was approved by the Internet Engineering Steering Group (IESG). BUT not every IESG-approved doc is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious about that 👀

If you want the current status, errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc7755 ✨

Copyright (c) 2016 IETF Trust and the people listed as authors. All rights reserved 💖

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they stood on the publication date. Please actually read those, bc they spell out your rights and restrictions 🙈

If you pull any Code Components out of this doc, they have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come with no warranty, as the Simplified BSD License says 💅

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Single-Stack IPv6 Operation . . . . . . . . . . . . . . .   3
  1.2.  Stateless Operation . . . . . . . . . . . . . . . . . . .   4
  1.3.  IPv4 Address Conservation . . . . . . . . . . . . . . . .   4
  1.4.  Clients' IPv4 Source Addresses Visible to Applications  .   5
  1.5.  Compatible with Standard IPv4 and IPv6 Stacks . . . . . .   5
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
3.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   8
  3.1.  Packet Flow . . . . . . . . . . . . . . . . . . . . . . .   9
4.  Deployment Considerations and Guidelines  . . . . . . . . . .  10
  4.1.  Application/Device Support for IPv6 . . . . . . . . . . .  10
  4.2.  Application Support for NAT . . . . . . . . . . . . . . .  10
  4.3.  Application Communication Pattern . . . . . . . . . . . .  10
  4.4.  Choice of Translation Prefix  . . . . . . . . . . . . . .  11
  4.5.  Routing Considerations  . . . . . . . . . . . . . . . . .  12
  4.6.  Location of the SIIT-DC Border Relays . . . . . . . . . .  12
  4.7.  Migration from Dual Stack . . . . . . . . . . . . . . . .  13
  4.8.  Translation of ICMPv6 Errors to IPv4  . . . . . . . . . .  13
  4.9.  MTU and Fragmentation . . . . . . . . . . . . . . . . . .  13
    4.9.1.  IPv4/IPv6 Header Size Difference  . . . . . . . . . .  14
    4.9.2.  IPv6 Atomic Fragments . . . . . . . . . . . . . . . .  14
    4.9.3.  Minimum Path MTU Difference between IPv4 and IPv6 . .  15
  4.10. IPv4-Translatable IPv6 Service Addresses  . . . . . . . .  16
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
  5.1.  Mistaking the Translation Prefix for a Trusted Network  .  17
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
  6.2.  Informative References  . . . . . . . . . . . . . . . . .  18
Appendix A.  Complete SIIT-DC IDC Topology Example  . . . . . . .  21
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  24
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  24

1. Introduction ✨

okay so historically, dual stack [RFC4213] [RFC6883] has been the go-to way to move from an IPv4-only setup to one that can serve IPv6 users 🧚 But for IDC operators, dual stack has some real downsides compared to single stack 😩 Running two protocols instead of one means more complexity and more operational overhead, and the payoff stays tiny as long as big chunks of the public Internet are still mostly IPv4-only 💀 On top of that, dual stack doesn't do anything at all about running out of IPv4 addresses, which (at the time of writing) is a super pressing problem in most parts of the world 🍓

So some IDC operators would rather only operate one protocol in their data center while they get ready for the future 💜 That's where Stateless IP/ICMP Translation for IPv6 Data Center Environments (SIIT-DC) comes in ✨ Its design goals are:

  • Promote the deployment of native IPv6 services (cf. [RFC6540]).
  • Provide IPv4 service availability for legacy users with no loss of performance or functionality.
  • Ensure that the legacy users' IPv4 addresses remain visible to the nodes and applications located in the IPv6 network.
  • Conserve and maximize the utilization of the operator's public IPv4 addresses.
  • Avoid introducing more complexity than absolutely necessary, especially on the nodes and applications.
  • Easy to scale and deploy in a fault-tolerant manner.

The next subsections break down how SIIT-DC hits these goals 🫶

1.1. Single-Stack IPv6 Operation 🌸

SIIT-DC lets IDC operators build their infrastructure and applications on an IPv6-only base 💖 IPv4 end-user connectivity becomes a service the network provides, so the sysadmin and app dev folks don't have to stress about it 🙈 That's how you get universal IPv6 deployment across the operator's services and apps, iconic 👑

SIIT-DC doesn't need any special support or changes from the underlying IPv6 infrastructure. It works with all standard IPv6 networks ✨ Traffic between IPv6-enabled end users and IPv6-enabled services is always carried natively, end to end. SIIT-DC doesn't intercept or handle native IPv6 traffic at all 🦋

And when the day comes to shut off all IPv4 support, the overall architecture doesn't change at all. You just turn off the SIIT-DC Border Relays (BRs) 🔥 Operators who deploy native IPv6 alongside SIIT-DC skip any future migration or deployment projects for IPv6 deployment and/or IPv4 sunsetting. Main character energy 💅

1.2. Stateless Operation 🎀

Here's what makes SIIT-DC different. Other solutions either give dual-stack availability to single-stack services, like Stateful Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) [RFC6146] and Layer 4/7 proxies, or they conserve IPv4 addresses, like IPv4 address translation (NAPT44) [RFC3022]. SIIT-DC doesn't keep any state about individual connections or flows 🧚 So in that sense it acts exactly like a regular IP router and has similar scaling properties. The limits are packets per second and bandwidth. The number of concurrent flows and the flow initiation rate don't matter for performance at all ✨

This means individual BRs can easily hit "line-rate" performance. It also allows per-packet load balancing across multiple BRs using Equal-Cost Multipath Routing [RFC2991] 🌈 Asymmetric routing is fine too, which makes it easy to dodge suboptimal traffic patterns. The prefixes can be anycasted from all the BRs in the provider's network, so the most optimal path gets used, even when the best path in one direction is different from the best path in the opposite direction 🦋

Last but not least, stateless operation makes high availability easy. If a BR fails, its traffic can be rerouted onto another BR using a standard IP routing protocol 💖 Existing flows are affected no more than they would be by any other IP rerouting event 🫶

1.3. IPv4 Address Conservation 🍓

In most parts of the world, it's hard or even impossible to get generously sized IPv4 delegations from the Internet Numbers Registry System [RFC7020] 😭 That scarcity hits both end users and operators. They might be forced to buy IPv4 addresses from other operators just to cover their needs. That can be risky for business continuity, especially if no suitable block is for sale, and it can turn out to be prohibitively expensive 💸 Even so, an IDC operator will find that providing IPv4 service is still essential, because a large share of Internet end users still don't have IPv6 connectivity 🌸

A key goal of SIIT-DC is to shrink a data center operator's IPv4 address requirement to the absolute minimum. The operator can remove IPv4 addresses entirely from nodes and applications that don't need to talk to endpoints on the IPv4 Internet ✨ One example is servers in a supporting/backend role that only talk to other servers, like database servers, file servers, and so on. Another example is the network infrastructure itself, like router-to-router links, loopback addresses, and so on 🧚 Also, LAN prefix sizes always have to be rounded up to the nearest power of two (or larger, if you reserve space for future growth). So even more IPv4 addresses end up wasted without ever being used 😩

With SIIT-DC, the operator can pull these valuable IPv4 addresses off backend servers and network infrastructure and reassign them to the SIIT-DC service as IPv4 Service Addresses 💜 There's no requirement that IPv4 Service Addresses be assigned in an aggregated manner, so nothing gets lost to infrastructure overhead. Every single IPv4 address assigned to SIIT-DC can be used as an IPv4 Service Address 🔥

1.4. Clients' IPv4 Source Addresses Visible to Applications 👀

SIIT-DC uses the [RFC6052] algorithm to map the entire end-user IPv4 source address into a predefined IPv6 translation prefix 🦋 That means no information gets lost. The end user's IPv4 source address stays available to the application in the IPv6 network, so it can do things like geolocation, logging, abuse handling, and so forth 🎀

(part 1 of 5, more coming bestie 💖✨)

1.5. Compatible with Standard IPv4 and IPv6 Stacks 🎀

okay so the only thing you actually have to add is the BRs themselves 💅 nothing else in the network, the nodes, the apps, or anything else needs to change for SIIT-DC to work. it's giving invisible 🫥 IPv4 clients, IPv6 nodes, the IPv6 data center network, and the IPv4 Internet all just vibe with it and don't notice. SIIT-DC plays nicely with every standards-compliant IPv4 or IPv6 stack, so no drama ✨

2. Terminology ✨

okay bestie, here are the terms this doc uses, so we're all on the same page 📖

  • SIIT-DC Border Relay (BR): a device or logical function that does stateless protocol translation between IPv4 and IPv6. it MUST do so in accordance with [RFC6145] and [RFC7757]. no freelancing 🙅‍♀️
  • SIIT-DC Edge Relay (ER): a device or logical function that gives IPv4-only devices or app software "native" IPv4 connectivity. it's basically a BR's twin, but it lives close to the IPv4-only stuff it's supporting instead of at the IDC's outer border 🧚 the ER is optional, and [RFC7756] has the deets.
  • IPv4 Service Address: an IPv4 address that represents a node or service sitting in an IPv6 network. it's coupled to an IPv6 Service Address using an Explicit Address Mapping (EAM). packets sent to it get translated to IPv6 by the BR (and maybe back to IPv4 by an ER) before they reach the node or service 🦋
  • IPv4 Service Address Pool: one or more IPv4 prefixes routed to the BR's IPv4 interface. IPv4 Service Addresses get handed out from this pool. it doesn't have to be a "pool" per se, because it could also be one or more host routes (prefix length /32). the reason we like pools over host routes is IPv4 route aggregation and making it easy to provision new IPv4 Service Addresses 🌸
  • IPv6 Service Address: an IPv6 address assigned to an application, node, or service, either directly or indirectly (through an ER). it's coupled with an IPv4 Service Address using an EAM. IPv4-only clients talk to the IPv6 Service Address through SIIT-DC 💜
  • Explicit Address Mapping (EAM): a bidirectional coupling between an IPv4 Service Address and an IPv6 Service Address, configured in a BR or ER. when translating between IPv4 and IPv6, the BR/ER changes the address fields in the translated packet's IP header according to any matching EAM. the EAM algorithm is specified in [RFC7757] 🔥
  • Translation Prefix: an IPv6 prefix that the entire IPv4 address space gets mapped into, following the algorithm in [RFC6052]. the translation prefix is routed to the BR's IPv6 interface. when translating, a BR/ER inserts or removes the translation prefix in the address fields of the translated packet's IP header, unless an EAM exists for the IP address being translated 👑
  • IPv4-Translatable IPv6 Addresses: as defined in Section 1.3 of [RFC6052] 🎀
  • IDC: short for "Internet Data Center"; a data center whose main purpose is delivering services to the public Internet. SIIT-DC is mainly aimed at being deployed in an IDC. an IDC is usually run by an Internet Content Provider or a Managed Services Provider 🍓
  • SIIT: the Stateless IP/ICMP Translation Algorithm, as specified in [RFC6145] ✨
  • XLAT: short for "Translation". it shows up in figures to mark where a BR/ER uses SIIT [RFC6145] to translate IPv4 packets to IPv6 and vice versa 🌈

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]. these are the official BCP 14 keywords, so read them with that energy 🫶

3. Architectural Overview 🏗️

this section is the big-picture tour of the basic SIIT-DC architecture, so let's go 🦋

IPv6-capable user IPv4-only user <2001:db8::ab:cd> <203.0.113.50>

(the IPv6 Internet) (the IPv4 Internet)

+-[BR]---------<192.0.2.0/24>--------------+
EAM #1: 192.0.2.1,2001:db8:12:34::1
EAM #2..#n: [...]
XLAT Prefix: 2001:db8:46::/96
+------------<2001:db8:46::/96>------------+

(the IPv6-only data center network)

+--<2001:db8:12:34::1>--[v6-only server]-+

+-[2001:db8:12:34::1]--[v6-only app]-+
AF_INET6 socket
+------------------------------------+

+----------------------------------------+

Figure 1: SIIT-DC Architecture

okay in Figure 1, 192.0.2.0/24 is the IPv4 Service Address Pool 💖 individual IPv4 Service Addresses get assigned from this prefix, and traffic headed for it is routed to the BR's IPv4-facing network interface. there are no restrictions on how many IPv4 Service Address Pools you use or what their prefix length is, as long as they're all routed to the BR's IPv4-facing network interface 🌸

when the BR translates packets between IPv4 and IPv6, it uses EAM #1 to swap any occurrence of the IPv4 Service Address (192.0.2.1) with its matching IPv6 Service Address (2001:db8:12:34::1) 💅 addresses that don't match any EAM configured in the BR get translated by inserting or removing the translation prefix (2001:db8:46::/96); see Section 2.2 of [RFC6052] 🧚

the BR can be a separate device, or a logical function inside another multipurpose device, like an IP router. any number of BRs can exist at once in the IDC's network infrastructure, as long as they're all configured with the same translation prefix and an identical EAM Table 🫶

the IPv6 Service Address should be registered in DNS with an "IN AAAA" record, while its matching IPv4 Service Address should be registered with an "IN A" record. this makes sure IPv6-capable clients reach the app/service directly over native IPv6 end to end, while IP4-only clients go through SIIT-DC 🦋

3.1. Packet Flow ✈️

okay so in this example, the "IPv4-only user" from Figure 1 starts a connection to the app running on the IPv6-only server 😭 first they look up the "IN A" record in DNS, then they send a TCP SYN packet to the IPv4 Service Address. that IPv4 packet gets routed to the BR and translated to IPv6 like this:

+--[IPv4]----------+ +--[IPv6]-----------------------+

SRC 203.0.113.50SRC 2001:db8:46::203.0.113.50
DST 192.0.2.1-->DST 2001:db8:12:34::1
TCP SYN [..]TCP SYN [..]

+------------------+ +-------------------------------+

Figure 2: IPv4-to-IPv6 Translation

the resulting IPv6 packet gets routed to the IPv6-only server, which handles it and responds like it was a native IPv6 packet the whole time 🔥 the server's IPv6 response then gets routed back to the BR, where it's translated back to IPv4:

+--[IPv6]-----------------------+ +--[IPv4]----------+

SRC 2001:db8:12:34::1SRC 192.0.2.1
DST 2001:db8:46::203.0.113.50-->DST 203.0.113.50
TCP SYN/ACK [..]TCP SYN/ACK [..]

+-------------------------------+ +------------------+

Figure 3: IPv6-to-IPv4 Translation

it's really important to know that neither the IPv4 client nor the IPv6 server/application needs any special support to take part in SIIT-DC 🙌 that said, the app may optionally be taught to pull the embedded IPv4 source address out of incoming IPv6 packets whose source addresses are inside the translation prefix. that lets it do IPv4-specific stuff like geolocation, logging, abuse handling, and so on 💜

4. Deployment Considerations and Guidelines 🌷

4.1. Application/Device Support for IPv6 💻

okay so SIIT-DC, as described in this doc, requires that the app (and/or the node it lives on) supports IPv6 networking and has no dependency on local IPv4 network connectivity 🙈

SIIT-DC can still support legacy IPv4-dependent apps and nodes, though, by bringing in an ER. the ER gives the legacy app or node seemingly native IPv4 Internet connectivity, so it can work properly in an otherwise IPv6-only network environment 🧚 this approach is covered in more detail in [RFC7756].

4.2. Application Support for NAT 🔄

the operator should carefully check whether the application protocols they want to use with SIIT-DC can work in a network where IP addresses get rewritten 👀 generally speaking, if an application-layer protocol works fine through standard NAT44 (see [RFC3235]), it will most likely work fine through SIIT-DC too 🎀

higher-level protocols that embed IP addresses in their payload are especially problematic [RFC2663] [RFC2993] [RFC3022] 😬 one well-known example is FTP [RFC959]. these protocols can be made to work with SIIT-DC by bringing in an ER, which provides end-to-end IPv4 address transparency by reversing the translations the BR performed before handing the packets to the NAT-incompatible application. this approach is described in more detail in [RFC7756] 🫶

4.3. Application Communication Pattern 📡

SIIT-DC is best suited for traditional client/server apps, where IPv4-only clients on the Internet start traffic toward an IPv6-only service that passively listens for inbound traffic and responds as needed 💖 in this case, an IPv4 client looks exactly like a native IPv6 client from the IPv6 service's point of view, so it doesn't need any special treatment ✨ one super common app protocol that follows this client/server pattern, and is therefore ideally suited for SIIT-DC, is HTTP [RFC7230] 🌈

it's also possible to combine SIIT-DC with DNS64 [RFC6147] so an IPv6-only app can start communication with IPv4-only nodes through SIIT-DC 🧚 however, in this case, you have to be careful that all outgoing communication is sourced from an IPv6 Service Address that's found in an EAM configured in the BR. if another address gets used, the BR will most likely be unable to translate it to IPv4, and the packet gets discarded 😭 you could prevent this by changing the Default Address Selection Policy Table [RFC6724] on the IPv6 node 🔧

another option is to put an ER in front of the app in question, as described in [RFC7756] 💅 this gives the app seemingly native IPv4 connectivity, which it can use freely for bidirectional communication with the IPv4 Internet. an app or node behind an ER doesn't need to worry about picking a specific source address, because it'll only have valid options available 🙌

4.4. Choice of Translation Prefix 🎀

Bestie, you can use either a Network-Specific Prefix (NSP) from the provider's own IPv6 address space, or the IANA-allocated Well-Known Prefix (WKP) 64:ff9b::/96. ngl, both work equally well ✨. BUT there is only ONE WKP in existence 💀, so if a provider wants to run more than one instance of SIIT-DC, or another translation technology like Stateful NAT64 [RFC6146], the operator will be forced to use an NSP for all but one of those deployments.

Another thing to know is that the WKP cannot be used in inter-domain routing 🌸. By using an NSP instead, SIIT-DC supports a deployment where the BR and the IPv6 Service Address live in different Autonomous Systems 🦋.

The translation prefix may use any of the lengths described in Section 2.2 of [RFC6052], but /96 has two distinct advantages over the others 👑. First, converting it to IPv4 can be done in a single operation by simply stripping off the first 96 bits 💅. Second, it lets IPv4 addresses be embedded straight into the text form of an IPv6 address using the familiar dotted quad notation, e.g., 2001:db8::198.51.100.10 (cf. Section 2.4 of [RFC6052]), instead of being converted to hexadecimal notation. This makes it way easier to write literal IPv6 addresses (e.g., in ACLs) that match translated endpoints in the IPv4 Internet 🫶.

For the reasons above, this document recommends that an NSP with a prefix length of /96 be used. Section 3.3 of [RFC6052] discusses the choice of the translation prefix in more detail 🧚.

4.5. Routing Considerations 🌈

The prefixes that make up the IPv4 Service Address Pool and the IPv6 translation prefix may be routed to the BRs like any other IPv4 or IPv6 route in the provider's network. If more than one BR is being deployed, it is recommended that a routing protocol (IGP) be used to advertise the routes within the provider's network. This makes sure the traffic that needs translating reaches the closest BR, reducing or eliminating suboptimal traffic patterns, and it gives you high availability: should one BR fail, the IGP will automatically redirect traffic to the closest alternate BR 🔥.

4.6. Location of the SIIT-DC Border Relays ✨

The goal of SIIT-DC is to facilitate a true IPv6-only application and network architecture, with the sole exception being the IPv4 interfaces of the BRs and the network infrastructure required to connect the BRs to the IPv4 Internet. Therefore, the BRs must be located somewhere between the IPv4 Internet and the application delivery stack, which includes all servers, load balancers, firewalls, intrusion detection systems, and similar devices that are processing traffic to a greater extent than merely forwarding it.

It is optimal to place the BRs as close as possible to the direct path between the location of the IPv6 Service Address and the end users. If the closest BR was located a long way from the direct path, all packets in both directions must make a detour to traverse the BR. This would increase the RTT between the service and the end user by two times the extra latency incurred by the detour, as well as cause unnecessary load on the network links on the detour path 😭.

Where possible, it is beneficial to implement the BRs as a logical function within the routers that also handle the native IPv6 traffic between the IPv6 Service Address and the IPv6 Internet. This way, an SIIT-DC deployment does not require separate network ports (which might become saturated and impact the service quality), nor will it require extra rack space and energy. Some particularly good choices for the location could be within the IDC's access routers or within the Autonomous System's border routers 💜.

Finally, another possibility is that the IDC operator outsources the SIIT-DC service to another entity, for example, their upstream ISP. Doing so allows the IDC operator to build a true IPv6-only infrastructure 🍓.

4.7. Migration from Dual Stack 🦋

While this document mainly discusses the use of IPv6-only nodes and applications, it is important to note that SIIT-DC is fully compatible with dual-stack infrastructures, including dual-stack nodes and applications.

Thus, migrating a dual-stacked service to an IPv6-only one where SIIT-DC provides the IPv4 Internet connectivity is easy. The operator would start out by designating the service's current native IPv6 address as the IPv6 Service Address and assigning it a corresponding IPv4 Service Address. At this point, the service will respond on both its old (native) IPv4 address and the SIIT-DC IPv4 Service Address. The operator may now move traffic from the former to the latter by changing the service's "IN A" DNS record. Once all IPv4 traffic has been successfully moved to SIIT-DC, the old IPv4 address may be reclaimed.

4.8. Translation of ICMPv6 Errors to IPv4 💀

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 an 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 packet sizes and fragmentation that one MUST consider when deploying SIIT-DC. They result in a few problematic corner cases, which can be dealt with in a few different ways. The following subsections will discuss these in detail and provide operational guidance.

In particular, the operator may find that relying on fragmentation in the IPv6 domain is undesired or even operationally impossible [FRAGMENTS]. For this reason, the recommendations in this section seek to minimize the use of IPv6 fragmentation.

Unless otherwise stated, the following subsections assume that the MTUs in both the IPv4 and IPv6 domains are 1500 bytes.

4.9.1. IPv4/IPv6 Header Size Difference 🎀

The IPv6 header is up to 20 bytes larger than the IPv4 header. This means that a full-size 1500 bytes large IPv4 packet cannot be translated to IPv6 without being fragmented, otherwise it would likely have resulted in a 1520 bytes large IPv6 packet.

If the transport protocol used is TCP, this is generally not a problem. The IPv6 node will advertise a TCP Maximum Segment Size (MSS) of 1440 bytes during the initial TCP handshake. This causes the IPv4 clients to never send larger packets than what can be translated to a single full-size IPv6 packet, eliminating any need for fragmentation 🧚.

For other transport protocols, full-size IPv4 packets with the Don't Fragment (DF) flag cleared will need to be fragmented by the BR. This may be avoided by increasing the Path MTU between the BR and the IPv6 nodes to 1520 bytes or greater. If this is done, the MTU on the IPv6 nodes themselves SHOULD NOT be increased accordingly, as doing so would cause them to undergo Path MTU Discovery for all destinations on the IPv6 Internet. The nodes MUST, however, be able to accept and process incoming packets larger than their own MTU. If the nodes' IPv6 implementation allows the initial Path MTU to be set differently for specific destinations, it MAY be increased to 1520 for destinations within the translation prefix specifically.

4.9.2. IPv6 Atomic Fragments 💅

In keeping with the fifth paragraph of Section 4 of [RFC6145], a stateless translator like a BR will by default add an IPv6 Fragmentation header to the resulting IPv6 packet when translating an IPv4 packet with the DF flag set to 0. This happens even though the resulting IPv6 packet isn't actually fragmented into several pieces, resulting in an IPv6 Atomic Fragment [RFC6946]. These Atomic Fragments are generally not useful in an IDC environment, so it is therefore recommended that this behavior be disabled in the BRs. To this end, Section 4 of [RFC6145] notes that the "translator MAY provide a configuration function that allows the translator not to include the Fragment Header for the non-fragmented IPv6 packets."

Note that work is currently in progress (in [RFC6145bis]) to deprecate IPv6 Atomic Fragments. As a result, a BR that conforms to that document is required to behave as recommended above.

In IPv6, the Identification value is located inside the Fragmentation header. That means that if the generation of IPv6 Atomic Fragments is disabled, the IPv4 Identification value will be lost during translation to IPv6. This could potentially confuse some diagnostic tools 🙈.

4.9.3. Minimum Path MTU Difference between IPv4 and IPv6 ✨

okay so Section 5 of [RFC2460] says the minimum IPv6 link MTU is 1280 bytes 🧚. That means an IPv6 node can reasonably assume that if it sends a packet that's 1280 bytes or smaller, it is guaranteed to reach its destination without needing fragmentation or invoking the Path MTU Discovery algorithm [RFC1981]. Super comforting, right? 💖 BUT this assumption might prove false if the destination is an IPv4 node reached through a protocol translator like a BR, because the minimum IPv4 link MTU is 68 bytes 😭. See Section 3.2 of [RFC791].

Here's the plot twist 🍓. Section 5.1 of [RFC6145] says a stateless translator should set the IPv4 Don't Fragment flag to 1 when it translates a non-fragmented IPv6 packet to IPv4. So if the path to the destination IPv4 node has an IPv4 link with an MTU smaller than 1260 bytes (which lines up with an IPv6 MTU smaller than 1280 bytes; cf. Section 4.9.1), the Path MTU Discovery algorithm gets invoked, even if the original IPv6 packet was only 1280 bytes large 🙈. The chain goes like this: the IPv4 router connecting to that small-MTU link sends back an ICMPv4 Need To Fragment error with an MTU value smaller than 1260. The BR then translates that into an ICMPv6 Packet Too Big error with an MTU value smaller than 1280, and that gets sent to the origin IPv6 node. It's giving domino effect 💀.

When an IPv6 node gets an ICMPv6 Packet Too Big error indicating an MTU value smaller than 1280, it is not allowed to reduce its Path MTU estimation to that value 🚫. It must instead include a Fragmentation header in subsequent packets sent on that path [RFC1981]. In other words, the IPv6 node will start emitting Atomic Fragments 🦋. The Fragmentation header tells the BR that the Don't Fragment flag should be set to 0 in the resulting IPv4 packet, and it also carries the Identification value.

If using the IPv6 Fragmentation header causes problems, the operator should consider turning on the functionality described as the "second approach" in Section 6 of [RFC6145] 🔧. This changes the BR's behavior in two ways:

  • When translating ICMPv4 Need To Fragment to ICMPv6 Packet Too Big, the resulting packet will never contain an MTU value lower than 1280. This prevents the IPv6 nodes from generating Atomic Fragments.
  • When translating IPv6 packets smaller than or equal to 1280 bytes, the Don't Fragment flag in the resulting IPv4 packet will be set to 0. This ensures that if the path contains an IPv4 link with an MTU smaller than 1260, the IPv4 router connected to that link will be the one responsible for fragmenting the packet before forwarding it towards its destination 🫶.

In summary, this approach kind of prompts IPv4 itself to provide the "link-specific fragmentation and reassembly at a layer below IPv6" that links "cannot convey a 1280-octet packet in one piece" need, to paraphrase Section 5 of [RFC2460] ✨.

Heads up 👑: work is currently in progress (in [RFC6145bis]) to deprecate IPv6 Atomic Fragments. So a BR that conforms to that document is required to behave as suggested above. Main character energy for the BR 💅.

4.10. IPv4-Translatable IPv6 Service Addresses 🌈

SIIT-DC is designed so that the IPv6 Service Addresses are not required to be IPv4-translatable IPv6 addresses 🎀. Section 2 of [RFC7757] explains why it's desirable to avoid requiring IPv4-translatable IPv6 addresses.

It is, however, totally possible to deploy SIIT-DC together with IPv4-translatable IPv6 Service Addresses 🧁. The main perks of doing that are:

  • The operator doesn't have to provision EAMs for IPv4-translatable IPv6 Service Addresses onto the BR/ERs.
  • [RFC6145] translation can be performed in a checksum-neutral manner; cf. Section 4.1 of [RFC6052] ✨.

The trade-off is that the IPv4-translatable IPv6 Service Addresses must be configured on the IPv6 nodes, and the applications must be set up to use them -- likely in addition to their primary (non-IPv4-translatable) IPv6 addresses 😩. The IPv4-translatable IPv6 Service Addresses must also be routed from the BR through the IDC's IPv6 network infrastructure to the nodes they're assigned to. That basically means the entire IPv6 infrastructure has to be aware of translated IPv4 traffic and handle it as a special case, which bumps up complexity a LOT 📈. As mentioned in Section 1.1, avoiding these drawbacks is a design goal of SIIT-DC 🦋. So the use of IPv4-translatable IPv6 Service Addresses is therefore discouraged 🙅‍♀️.

5. Security Considerations 🔐

5.1. Mistaking the Translation Prefix for a Trusted Network 👀

If a Network-Specific Prefix from the provider's own address space is chosen for the translation prefix, as recommended in Section 4.4, care MUST be taken if the translation service sits in front of services with application-level ACLs that tell apart the operator's own networks from the Internet at large 🚨. Traffic from translated IPv4 end users on the Internet might look like it's coming from the provider's own network, and that's a whole mess 😱. So it's important to treat the translation prefix the same as the Internet at large, NOT as a trusted network 💜.

To help alleviate this, the operator may opt to use a translation prefix that is distinct from, and not a subset of, the IPv6 prefixes used elsewhere in the network infrastructure 🌸.

6. References 📚

6.1. Normative References

6.2. Informative References

Appendix A. Complete SIIT-DC IDC Topology Example 🧩✨

Figure 4 is the "tie it all together" moment 💅. It shows a bigger SIIT-DC topology so you can see the advantages from Section 1 actually working in one picture 🦋.

                  /--------------------------------\ /---------------\
                  |          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             |  |
     | 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)

Figure 4: Example SIIT-DC IDC Topology

Single-Stack IPv6 Operation 🌈

As discussed in Section 1.1, SIIT-DC makes an IPv6-only IDC network infrastructure possible 🫶. The only places where IPv4 is absolutely required are between the BRs and the IPv4 Internet, and between any ERs and the IPv4-only applications or devices they serve (here, the two tenants' FTP servers). The figure also shows that SIIT-DC does not interfere with native IPv6 ✨. When nobody needs IPv4 clients anymore, the BRs may be decommissioned without causing any impact to native IPv6 traffic 💖.

Stateless Operation 🦋

As discussed in Section 1.2, SIIT-DC operates in a stateless fashion 💅. In the picture, both BRs are advertising (anycasting) the IPv4 Service Address Pool and the IPv6 translation prefix at the same time 👯. So incoming traffic from the IPv4 Internet can land on either BR, and outgoing IPv6 traffic going to IPv4 endpoints gets load balanced between them using Equal-Cost Multipath Routing 🔥. No continuous state synchronization between the two BRs happens, so it's not a whole thing 🙈. If one BR fails, BGP and OSPF make sure traffic converges on the remaining BR 🧚. Existing sessions aren't disrupted beyond whatever disruption the BGP/OSPF convergence process itself causes 💀.

IPv4 Address Conservation 🍓

As discussed in Section 1.3, SIIT-DC saves the IDC operator's IPv4 address space 💜. Even though the two customers in the example have several hundred servers, most of those servers aren't running services made available directly from the Internet, so they don't need to eat up IPv4 addresses 😭. The IDC network infrastructure uses zero IPv4 addresses too 🌸. And the IPv4 addresses assigned to the SIIT-DC function as IPv4 Service Address Pools can be handed out with 100% efficiency, one address at a time 🎀. There is no requirement to give a customer multiple addresses in a contiguous block, which is so iconic ✨.

Application Support 👑

As discussed in Section 1.5, as long as the application protocol is translation friendly (HTTP and SMTP are the examples here), it works with SIIT-DC without needing any special adaptation 🫶. Translation-unfriendly applications like FTP still work when they sit behind an ER [RFC7756] 🌈. Tenant A's FTP server shows how an ER can live inside the networking stack of a node, while Tenant B's FTP server shows how the ER can be deployed as a network service 💅. The second approach is the one that lets SIIT-DC support IPv4-only nodes and devices, periodt 🔥.

Acknowledgements 🫶

The author would like to thank the following people for their contributions, suggestions, corrections, and criticisms 💖: Fred Baker, Cameron Byrne, Brian E. Carpenter, Ross Chandler, Tobias Gondrom, Christer Holmberg, Dagfinn Ilmari Mannsaaker, Lars Olafsen, Stig Sandbeck Mathisen, Knut A. Syed, Qin Wu, and Andrew Yourtchenko 🌸✨.

Author's Address 📬

Tore Anderson
Redpill Linpro
Vitaminveien 1A
0485 Oslo
Norway

Phone: +47 959 31 212
Email: tore@redpill-linpro.com
URI:   http://www.redpill-linpro.com
📦 where this page comes from