GENEVE through NAT64

Overview

This repository contains a proof-of-concept implementation of GENEVE tunnel endpoints utilizing a NAT64 extension. This can be used to establish a GENEVE tunnel between two IPv6 sites with NAT64 even if there is no native IPv6 path between the two sites.

The extension requires support by both endpoints and by the NAT64 gateway used by at least one of the endpoints. If one the endpoints has native IPv6 access it can make use of my public NAT64 gateway which has external IPv4 address 95.216.219.126. The other endpoint can use any NAT64 implementation even if that NAT64 is itself connected to the internet through NAT444. If both of your endpoints have native IPv6 access you don't need the extension provided here.

The extension can be used in three different operating modes described in further detail below.

Symmetric: This mode is the simplest, but it requires both endpoints to use a NAT64 which implements the GENEVE extension. Moreover it will not work if any other NAT is present on the path.
Client-Server: This mode works when the server has a NAT64 with the GENEVE extension and a public IPv4 address. The client can use IPv4 or any NAT64 without the extension and the client connection can involve additional layers of NAT.
NAT-auto-detection: The endpoint implementation provided in this repository does not yet implement this mode. This mode works as long as either endpoint has a NAT64 with the GENEVE extension and a public IPv4 address. The other endpoint can use any NAT64 with or without the GENEVE extension and that NAT64 may be connected through NAT444.

Downloading the software

The software can be downloaded using the following command:

  hg clone https://v6tools.kasperd.dk/geneve-through-nat64

Running a symmetric tunnel

On each end of the tunnel you will need to run geneve.py with four arguments. The four arguments are:

Virtual network identifier. This is a number from 0 to 1677215. You must use the same number on both sides. The software in this repository only supports use of one VNI at a time. Other GENEVE software can use multiple VNI simultaneously to create separate VLANs.
Local endpoint address. This is a static IPv6 address. The endpoint must be able to use this IPv6 address when communicating with the NAT64.
NAT64 path. This argument is a single IPv6 address which combines the NAT64 prefix used by the local site and the external IPv4 address used by the remote NAT64.
Remote endpoint address. This must be the same as the local endpoint address assigned to the other endpoint.

Example of what the commands used for the two endpoints of a tunnel can look like:

geneve-through-nat64/geneve.py 42 2001:db8:a::1 64:ff9b::203.0.113.90 2001:db8:b::1
geneve-through-nat64/geneve.py 42 2001:db8:b::1 64:ff9b::198.51.100.7 2001:db8:a::1

Running a client-server tunnel

In client server mode the server must have access to communicate with a NAT64 which supports the GENEVE extension and has a public IPv4 address. The server is started using server.py and takes only three argument as the NAT64 path is not provided. The NAT64 path will be automatically discovered when the client connects. The server implementation in this repository only supports a single connected client at any given time.

Example command for starting the server:

geneve-through-nat64/server.py 42 2001:db8:a::1 fdd9:f2f4:ed01::1

The client needs IPv4 access which can be through a NAT64 gateway without support for the GENEVE extension. If both sides are using a NAT64 with the extension you need to use symmetric or auto-detect mode instead. The client command line includes the same arguments as in symmetric mode, except that the path does not have to be an IPv6 address but can instead be a hostname or an IPv4 address.

Example command for starting the client:

geneve-through-nat64/client.py 42 fdd9:f2f4:ed01::1 geneve-entry-point.nat64.dk 2001:db8:a::1

Caveats

The code in this repository is not fast or flexible. It is primarily intended as a proof of concept. I hope more GENEVE endpoints will add support for this extension such that you can use your favorite GENEVE implementation to communicate. I also hope to see more NAT64 gateways implement this extension.

The tunnel does not make use of any cryptography. Communication through the tunnel can be intercepted. You should treat it as no more secure than a public network. All communication inside the tunnel should be done using secure protocols.