SIIT-DC: IPv4 Service Continuity for IPv6 Data Centres. Tore Anderson Redpill Linpro AS 8th Belgian IPv6 Council, Bruxelles, November 2015

Transcription

1 SIIT-DC: IPv4 Service Continuity for IPv6 Data Centres Tore Anderson Redpill Linpro AS 8th Belgian IPv6 Council, Bruxelles, November 2015

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, draft-ietf-v6ops-siit-eam, draft-ietf-v6ops-siit-dc

4

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 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 [...]

7

8

9

10

11

12

13 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 draft-ietf-v6ops-siit-dc-2xlat

14

15

16 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

17 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.]

18 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

19 Questions? Thank you for listening! Further reading: RFC IPv6 Addressing of IPv4/IPv6 Translators RFC IP/ICMP Translation Algorithm draft-ietf-v6ops-siit-eam - Explicit Address Mappings for Stateless IP/ICMP Translation draft-ietf-v6ops-siit-dc - SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments draft-ietf-v6ops-siit-dc-2xlat - 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.)