1. SIIT-DC: IPv4 Service Continuity for IPv6 Data Centres
Tore Anderson
Redpill Linpro AB | AS | A/S
Internetdagarna 2016, Stockholm, November 2016

2. Why build IPv6-only data centres?
IPv4 scarcity - we can no longer build on public IPv4 addresses
Using RFC1918 addresses is not an desirable workaround
Will require us to deploy stateful NAT44
Overlaps when connecting with VPN to customers/suppliers/etc
Avoid dual-stack (with or without RFC1918)
Dual work, dual complexity, dual faults, dual monitoring, ...
Only IPv6 facilitates a truly scalable and uniform architecture
One size fits all, never ever expand a subnet or allocation again

3. We still need IPv4 service continuity
>90% of our Internet traffic is still IPv4, therefore:
We cannot degrade IPv4 performance
We cannot degrade IPv4 stability
The solution must be simple and easily understood
The solution must work with standard IPv6 nodes and networks
The solution must ensure efficient use of public IPv4 addresses
Stateless IP/ICMP Translation for Data Centres (SIIT-DC)
Think of it as «Stateless Layer-3-only NAT64»
RFC 6052, RFC 6145, RFC 7755, RFC 7756, RFC 7757

4. IPv4<->IPv6 translators
The IPv4 Internet
The IPv6 Internet
IPv6 data centre network
IPv4<->IPv6 translators

5. SIIT-DC operation in a nutshell
The IPv4 internet is mapped into an IPv6 translation prefix
IPv /0 -> IPv6 2001:db8:46:: /96 [or: 2001:db8:46::/96]
For example: > 2001:db8:46:: [or: 2001:db8:46::cb00:710a]
A table of explicit 1:1 IPv4:IPv6 mappings determine which IPv6 addresses are reachable through which IPv4 addresses
A pool of public IPv4 addresses is required - use your last /22, for example
> 2001:db8:dc1::80 (“web server in data centre 1”)
> 2001:db8:dc2::25 (“smtp server in data centre 2”)
> 2001:db8:dc1::389 (“ldap server in data centre 1”)
> 2001:200:dff:fff1:216:3eff:feb1:44d7 (kame.net - somewhere on the Internet)
[...]

6. SIIT-DC packet flow: client->server
IPv6 server
(2001:db8:dc2::25)
IPv4 client
( )
IPv4:IPv6
translation
IPv4
Src:
Dst:
Src:
Dst:
The IPv4 internet
The IPv6 data centre
The IPv4 address is published in DNS as an «IN A» IPv4 address for the service's host name
The client initiates traffic to this address as it would to any other regular IPv4 address
The IPv4 destination address (or its encompassing prefix) is routed to the translation service
This follows standard IPv4 forwarding paths as defined by BGP, OSPF, static routes, or whatever

7. SIIT-DC packet flow: client->server
IPv6 server
(2001:db8:dc2::25)
IPv4 client
( )
IPv4:IPv6
translation
IPv6
IPv4
2001:db8:46::
2001:db8:dc2::25
Src:
Dst:
Src:
Dst:
The IPv4 internet
The IPv6 data centre
The IPv4 header is rewritten to IPv6
The IPv6 translation prefix (2001:db8:46::/96) is prepended to the original IPv4 source address
The original IPv4 destination address is swapped according to the explicit IPv4:IPv6 mapping
Layer 4 payload is copied verbatim

8. SIIT-DC packet flow: client->server
IPv6 server
(2001:db8:dc2::25)
IPv4 client
( )
IPv4:IPv6
translation
IPv6
Src:
Dst:
Src:
Dst:
2001:db8:46::
2001:db8:dc2::25
The IPv4 internet
The IPv6 data centre
The translated IPv6 packet is routed to the server
This also follows standard IPv6 routing paths
The server processes to the packet as it would for any other IPv6 client request
Notice how the original IPv4 address of the client remains visible to the server

9. SIIT-DC packet flow: server->client
IPv6 server
(2001:db8:dc2::25)
IPv4 client
( )
IPv4:IPv6
translation
IPv6
Src:
Dst:
2001:db8:dc2::25
2001:db8:46::
Src:
Dst:
The IPv4 internet
The IPv6 data centre
The servers' IPv6 response packet is routed to the translation service as the destination address falls within the translation prefix (2001:db8:46::/96)
Again, this follows standard IPv6 routing paths

10. SIIT-DC packet flow: server->client
IPv6 server
(2001:db8:dc2::25)
IPv4 client
( )
IPv4:IPv6
translation
IPv6
IPv4
2001:db8:dc2::25
2001:db8:46::
Src:
Dst:
Src:
Dst:
The IPv4 internet
The IPv6 data centre
The IPv6 header is rewritten to IPv4
The server's IPv6 source address is swapped according to the explicit IPv4:IPv6 mapping
The IPv6 translation prefix (2001:db8:46::/96) is stripped from the IPv6 destination address
Layer 4 payload is copied verbatim

11. SIIT-DC packet flow: server->client
IPv6 server
(2001:db8:dc2::25)
IPv4 client
( )
IPv4:IPv6
translation
IPv4
Src:
Dst:
Src:
Dst:
The IPv4 internet
The IPv6 data centre
The translated IPv4 response packet is routed back to the client over the Internet
To the client, this is a completely standard IPv4 response and is processed accordingly

12. IPv4 dependencies and NAT incompatibility
SIIT-DC as presented so far requires:
That the application protocol works correctly through NAT
That the servers/devices in the data centre support IPv6
That the application software supports IPv6
Double translation overcomes these limitations
Reverses the IPv4->IPv6 translation done previously, before passing the packets to the IPv4-only software or device
Provides the application with dual-stack connectivity, using “virtualised” IPv4 - indistinguishable from native IPv4
See RFC 7756

13. Dual translation: Host centric
IPv6-only server
The IPv4 Internet
IPv6:IPv4
translation daemon
IPv6 data centre network
Virtual IPv4 NIC:
/32
IPv4:IPv6 translator
Native
IPv6
IPv4
Application software
(IPv4-only or NAT-unfriendly)
A software agent is installed on IPv6-only servers that run IPv4-only or NAT-incompatible applications
Performs the same translations as the translator in the network, only in reverse
Provides the application with local “native” IPv4 connectivity
The public/external IPv4 address is assigned directly to the virtual NIC, providing end-to-end address transparency (ensuring that self-referrals in application payload work, e.g., FTP)

14. Dual translation: Network centric
IPv4-only server
( )
The IPv4 Internet
IPv6 data centre network
IPv6:IPv4 translator
Isolated IPv4-only network
(or: dual-stack network with
native IPv6 and isolated IPv4)
IPv4:IPv6 translator
An IPv6:IPv4 translator is located close to the IPv4-only server/device, and creates an isolated IPv4-only network segment to which IPv4-only servers or devices can connect normally
Can pass through native IPv6 unmodified to support dual-stack servers/devices (e.g., if application software or protocols is IPv4-only or NAT-unfriendly and use of host-based translator is impossible)
Provides end-to-end transparency (the public/external IPv4 address is assigned directly to the server)

15. SIIT-DC is a completely stateless solution
No tracking of flows or connections - per-packet operation
Failover doesn't break existing connections like NAT44 would
Natively supports asymmetric traffic patterns
Use anycast, ECMP, standard routing protocols
Performance scales according to bps/pps
Concurrent session count or session initiaton rate is irrelevant
Operates and performs more like an IP router than a NAT box
The translation function may indeed run directly on your routers

16. It's really, really simple to set up
A complete Cisco ASR/CSR example config to the right
Other implementations exist
Brocade ADX, F5 BIG-IP LTM, Linux/TAYGA, Linux/Jool
On server: Linux/clatd/TAYGA
Incremental deployment
It doesn't require an IPv6-only network, just an IPv6 one (dual-stack networks like the Internet included) !
interface GigabitEthernet1
ip address
nat64 enable
nat64 settings mtu minimum 1500
ipv6 address 2001:db8::2/64
ip route
ip route Null0
ipv6 route ::/0 2001:db8::1
nat64 prefix stateful 2001:db8:46::/96
nat64 v6v4 static 2001:db8:dc1::
nat64 v6v4 static 2001:db8:dc2::
nat64 v6v4 static 2001:db8:dc1::
nat64 v6v4 static 2001:200:dff:fff1:216:3eff:feb1:44d
nat64 settings fragmentation header disable
nat64 settings flow-entries disable
[Never mind the «stateful», it's really stateless because of «flow-entries disable». The 10 lines that are directly related to SIIT-DC are highlighted in bold, the rest are just standard IPv4/IPv6 network connectivity. Note that /24 and 2001:db8:46::/96 must be routed to the ASR/CSR box somehow.]

17. Final words Maximum IPv4 conservation; 1 address per public service
Nothing wasted on network infrastructure, backend servers, rounding up LAN prefixes to nearest CIDR boundary, reservations for future growth, etc.
Single-stack simplicity - inside your network, it's all IPv6
IPv6-only ACLs, IPv6-only IGP, IPv6-only monitoring, IPv6-only monitoring, IPv6-only load balancers, IPv6-only firewalls, and so on
No architectural dependency on IPv4 remains
Source address of IPv4 clients is visible to the application
Geo-location, logging, abuse handling, etc. of IPv4 clients possible

18. Questions? Thank you for listening!
Further reading:
RFC IPv6 Addressing of IPv4/IPv6 Translators
RFC IP/ICMP Translation Algorithm
RFC Explicit Address Mappings for Stateless IP/ICMP Translation
RFC SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments
RFC SIIT-DC: Dual Translation Mode
- host-centric IPv4:IPv6 translator and 464XLAT CLAT for Linux
- My personal home page (contact info, social media links, slides from this and earlier talks)
- My personal technology blog
- My employer and sponsor of this project
(Of course, IPv4-only clients will access the three last URLs above via SIIT-DC. I do eat my own dog food, and it's tasty indeed.)