Carlos Martinez Cagnazzo

LACNIC

carlos @ lacnic.net

@carlosm3011

Painlessly Exposing IPv4-only Services on the IPv6 Internet

Unless you have been living under a rock…

• …you have probably heard something about IPv4 running out

Unless you have been living under a rock…

• … and thought that maybe it’s high time to do something about it

Exposing Services in IPv6

• This talk assumes that you control your DNS and can create records within your domains

• When exposing services in IPv6, going to full dual stack operation should always be the first choice

• But… sometimes this is not advisable or possible– For example:

• If you lack direct IPv6 connectivity but a partner does• If the servers cannot be modified or upgraded• If the software licensing is tied to IP addressing

The Challenge

• How can I expose an IPv4-only service to the IPv6 Internet?– Without reconfiguring the servers themselves at all– Preferably using open source, readily available software

Two Approaches

• Application layer-based:– HTTP reverse proxy

• Network layer-based:– Address / Protocol translation

HTTP Reverse Proxy

• Apache’s mod_proxy listening on an IPv6 address can perform reverse proxying to an IPv4 host

HTTP GET / Proxied-HTTP GET /

HTTP Reverse Proxy

• Apache’s mod_proxy can listen on an IPv6 address and perform reverse proxying to an IPv4 address:

<VirtualHost [2001:13c7:7001:4000::10]:80>

# Server names ServerName www.mnav.gub.uy ServerAlias www.mnav.gub.uy.prx64.labs.lacnic.net

# Logs CustomLog /home/v6v4Proxy/logs/mnav/access.log combined ErrorLog /home/v6v4Proxy/logs/mnav/error.log ProxyPass / http://www.mnav.gub.uy/ ProxyPassReverse / http://www.mnav.gub.uy/

</VirtualHost>

HTTP Reverse Proxy

• Pros– Simple to configure, just adapt the snippet from the previous

slide to your network setup and you are done– Server and proxy do not need to be on the same network

• Cons– HTTP-specific, other solutions would be needed for other

application protocols– HTML-related issues

• Embedded IPv4-literals will fail• Charset-related issues

– Proxy and web server must strictly agree on the charsets used– HTML-entities should be preferred (&aacute; for ‘á’)

A Network-layer Approach

• Meet NAT64 !– Connect IPv6-only clouds with IPv4-only clouds– Translate protocol headers including addresses

• Destination IPv4 address is embedded / encoded in IPv6 destination address

• Source IPv4 address for translated packet:– Multiplexed using TCP / UDP port numbers: Stateful NAT64– One-to-one mapping: Stateless NAT64

NAT64 High Level Description

• Traffic flows started from an IPv6-only host are translated into IPv4 and forwarded to IPv4-only hosts

• Protocol and address translation– Protocol: IPv6 <-> IPv4 header mapping– Address: IPv6 <-> IPv4 address mapping

• This mapping is obviously not one-to-one• A v6 prefix is chosen per network which will be used to

map the IPv4 space– A /96 is enough (32 bits), RFCs recommend using 64:ff9b::/96

IPv4 into IPv6 Address Mapping

• RFC 6052 defines algorithmic address mapping

NAT64 (ii)

• Protocol translation– For each IPv6 packet the NAT64 box receives it has to build an

IPv4 packet• Header field mapping• Address mapping IPv6 -> IPv4

– No one-to-one mapping is possible

– The NAT64 box needs at least one public IPv4 address for outgoing packets

• It needs to keep a state table, just like any NAT implementation

Stateful NAT64

IPv6 Packet

SRC: 2001:db8::128

DST: 64:ff9b::42dc:9e19

<<other headers>>

NAT64 Router

TCP Frame

SRC PORT: 32768

DST PORT: 80

IPv4 Packet

SRC: 190.216.38.14

DST: 69.63.190.18

<<other headers>>

TCP Frame

SRC PORT: 15547

DST PORT: 80

DSrc DDst Port1 Port2

2001:db8::128

69.63.190.18

32768

15547

Alg. Address Mapping

Stateless NAT64

IPv6 Packet

SRC: 2001:db8::128

DST: 64:ff9b::42dc:9e19

<<other headers>>

NAT64 Router

IPv4 Packet

SRC: 190.216.38.X

DST: 69.63.190.18

<<other headers>>

Algorithmic Address Mapping

SRC address is mapped one-to-one

to the IPv6 hosts

Introducing TAYGA

• TAYGA is a user-mode, stateless NAT64 implementation– Uses the TUN driver

• http://www.litech.org/tayga/ • (Full instructions on TAYGA’s website)

– Compile:• The usual ./configure && make && make install

– Create a config file /usr/local/etc/tayga.conf:– Create tun device and configure static routes and addresses

The case of http://www.isoc.org.uy

• ISOC’s local Uruguay chapter web is on a hosting service which does not support IPv6

• IPHH.net graciously donated a virtual machine with full dual-stack connectivity

Configuring TAYGA on the NAT64 box

• Configure TAYGA itself

tun-device nat64ipv4-addr 213.128.134.58prefix 2001:868:100:1b01:0:1::/96dynamic-pool 192.168.255.0/24data-dir /var/db/tayga

Configuring TAYGA on the NAT64 box

• Set up routes and NAT44 rules

ip link set nat64 upip addr flush dev nat64ip addr add 213.128.134.58 dev nat64ip addr add 2001:868:100:1b00::cafe dev nat64

ip route add 192.168.255.0/24 dev nat64ip route add 2001:868:100:1b01:0:1::/96 dev nat64

iptables -t nat -A POSTROUTING -s 192.168.255.0/24 -j SNAT \

--to-source 213.128.134.58iptables -A FORWARD -s 192.168.255.0/24 -i nat64 -j ACCEPT

NAT64 prefix

What is going on inside the NAT64 box ?

eth0(IPv6)

nat64

TAYGAeth0

(IPv4)

Incoming IPv6 packets

Outgoing IPv4 packets(public addressing)

IPv6

IPv6 IPv4 (priv)

NAT44

IPv4 (priv)

Creating the DNS records

• We map the public IPv4 of the server into the NAT64 prefix– Some servers may support mapped-IPv4 notation as follows:

• 2001:db8:1::200.40.20.1/64

– If not, you can either do the math, or, if you are lazy like me:

• Create the AAA record(s) that are necessary using the mapped IPv6 address

Ready? Let’s try it out

• http://www.isoc.org.uy

Want to try it out for your website?

• Drop me an email!

Thank you !

carlosm3011