## Introduction
NAT traversal can be roughly broken down into three main components:

1. the NAT decision function;
2. the traversal strategy selection algorithm;
3. the traversal strategies themselves.

In the scope of what is avaliable within libp2p and the Nim ecosystem, we could envision an algorithm like the one in Figure 1, which combines these elements into a fully-functional NAT traversal solution.

<center>
<image src="https://hackmd.io/_uploads/ryw4-zvBA.png"/>
</center>

**Figure 1.**

Rolling out the full NAT traversal solution, then, entails:

1. implementing the individual NAT traversal strategies;
2. implementing the strategy selection algorithm;
3. implementing the NAT decision function.

The key for a gradual rollout plan is the realization that:

1. strategies can be implemented incrementally;
2. the outcome of the NAT decision function can be specified by the user via a CLI switch;
3. one's external IP address can be specified by the user via a CLI switch;
4. the NAT traversal strategy to be adopted can be specified by the user via a CLI switch.

This means we can implement strategies without necessarily having an automated decision function, or even a strategy selection algorithm in place. It also means we can implement primitives like learning your own IP address through CLI parameters instead of having to figure out a way to provide a decentralized service to do that. This sets the tone for our rollout plan, which we lay out next.

## Tentative Rollout Plan

**Phase 1.** Codex currently supports overriding the IP address that gets announced in the DHT via the `--nat` switch, which means that a manual version of port forwarding is already supported.

For phase 1, therefore, we could roll out the ability to select NAT-PMP/UPnP as the traversal strategy. This would entail modifying the current `--nat` switch so it supports different traversal strategies; e.g.:

--nat-mode port-forward --external-address 17.3.0.1
--nat-mode upnp-nat-pmp

This can probably be done in a day or two.

**Phase 2.** Anything we do from here requires autonat, so for phase 2 I'd suggest:

1. enabling autonat, which means implementing public node discovery. This means:
1a. running public nodes in "client mode" in the DHT;
1b. implementing DHT sampling and the logic for maintaining locally visible public nodes for running autonat.
2. allowing autodiscovery of annouce addresses in port-forward.

This can probably be done in two weeks or slightly longer.

**Phase 3.** With autonat and public node discovery in place, we are in good shape to rollout circuit relay v2 and hole punching.

This can probably be done in one extra week.