diff --git a/doc/Design.tex b/doc/Design.tex
index e3fe357..b859932 100644
--- a/doc/Design.tex
+++ b/doc/Design.tex
@@ -3,31 +3,130 @@
 %               the architecture
 In this chapter we describe the architecture of our solution.
 
+% ----------------------------------------------------------------------
+\section{\label{design:configuration}IPv6 and IPv4 configuration}
+The following sections refer to host and network configurations. In
+this section we describe the IPv6 and IPv4 configurations as a basis
+for the discussion.
+
+All IPv6 addresses are from the documentation block
+\textit{2001:DB8::/32}~\cite{rfc3849}. In particular the following sub
+networks and IPv6 addresses are used:
+
+\begin{table}[htbp]
+\begin{center}\begin{minipage}{\textwidth}
+\begin{tabular}{| c | c |}
+\hline
+\textbf{Address} & \textbf{Description} \\
+\hline
+2001:db8:42::/64 & IPv6 host network \\
+\hline
+2001:db8:23::/96 & IPv6 mapping to the IPv4 Internet \\
+\hline
+2001:db8:42::42 & IPv6 host address \\
+\hline
+2001:db8:42::77 & IPv6 router address \\
+\hline
+2001:db8:42::a00:2a & In-network IPv6 address mapped to 10.0.0.42 (p4)\\
+\hline
+2001:db8:23::a00:2a & IPv6 address mapped to 10.0.0.42 (tayga) \\
+\hline
+2001:db8:23::2a & IPv6 address mapped to 10.0.0.42 (jool)\\
+\hline
+\end{tabular}
+\end{minipage}
+\caption{IPv6 address and network overview}
+\label{tab:ipv6address}
+\end{center}
+\end{table}
+
+We use private IPv4 addresses as specified by RFC1918~\cite{rfc1918}
+from the 10.0.0.0/8 range as follows:
+
+\begin{table}[htbp]
+\begin{center}\begin{minipage}{\textwidth}
+\begin{tabular}{| c | c |}
+\hline
+\textbf{Address} & \textbf{Description} \\
+\hline
+10.0.0.0/24 & IPv4 host network \\
+\hline
+10.0.1.0/24 & IPv4 network mapping to IPv6\\
+\hline
+10.0.0.77 & IPv4 router address\\
+\hline
+10.0.0.66 & In-network IPv4 address mapped to 2001:db8:42::42 (p4)\\
+\hline
+10.0.1.42 & IPv4 address mapped to 2001:db8:42::42 (tayga)\\
+\hline
+10.0.1.66 & IPv4 address mapped to 2001:db8:42::42 (jool)\\
+\hline
+\end{tabular}
+\end{minipage}
+\caption{IPv4 address and network overview}
+\label{tab:ipv4address}
+\end{center}
+\end{table}
+
+
 % ----------------------------------------------------------------------
 \section{\label{design:nat64}NAT64 with P4 - FIXME: elaborate}
-In section \ref{background:transition} we discussed different
-translation mechanisms for IPv6 and IPv4. In this thesis we focus on
-the translation mechansims stateless and stateful NAT64. While higher
-layer protocol dependent translations are more flexible, this topic
-has already addressed in
-\cite{nico18:_implem_layer_ipv4_ipv6_rever_proxy} and the focus in
-this thesis is on the practicability of high speed NAT64.
-The high level design can be seen in figure \ref{fig:switchdesign}: a
-P4 capable switch is running our code to provide NAT64
-functionality. The P4 switch cannot manage its tables on it own and
-needs support for this from a controller. If only static table entries
-are required, the controller can also be omitted. However stateful
-NAT64 requires the use of a control to create session entries in the
-switch tables.
 \begin{figure}[h]
   \includegraphics[scale=0.5]{switchdesign}
   \centering
   \caption{P4 Switch Architecture}
   \label{fig:switchdesign}
 \end{figure}
-The P4 switch can use any protocol to communicate with controller, as
+In section \ref{background:transition} we discussed different
+translation mechanisms for IPv6 and IPv4. In this thesis we focus on
+the translation mechansims stateless and stateful NAT64. While higher
+layer protocol dependent translations are more flexible, this topic
+has already been addressed in
+\cite{nico18:_implem_layer_ipv4_ipv6_rever_proxy} and the focus in
+this thesis is on the practicability of high speed NAT64.
+The high level design can be seen in figure \ref{fig:switchdesign}: a
+P4 capable switch is running our code to provide NAT64
+functionality. A P4 switch cannot manage its tables on it own and
+needs support for this from a controller. The controller also has the
+role to handle unknown packets and can modify the runtime
+configuration of the switch. This is especially useful in the case of
+stateful NAT64.
+If only static table entries
+are required, they can usually be added at the start of a P4 switch
+and the controller can also be omitted. However stateful
+NAT64 requires the use of a controller to create session entries in the
+switch tables.
+The P4 switch can use any protocol to communicate with the controller, as
 the connection to the controller is implemented as a separate ethernet
-port. The design allows our solution to be used as a standard NAT64
+port.
+\begin{figure}[h]
+  \includegraphics[scale=0.4]{v6-v4-standard}
+  \centering
+  \caption{Standard NAT64 translation}
+  \label{fig:v6v4standard}
+\end{figure}
+
+Software NAT64 solutions typically require routing to be applied to
+transport the packet to the NAT64 translator as shown in
+\ref{fig:v6v4standard}.
+
+Our design differs here: while routing could be used like described
+above, NAT64 with P4 does not require any routing to be setup. Figure
+\ref{fig:v6v4mixed} shows a network design that can be realised using
+P4. This design has multiple advantages: first it reduces the number
+of devices to pass and thus directly reduces the RTT. Secondly it
+allows translation of IP addresses within the same logic network
+segment.
+
+\begin{figure}[h]
+  \includegraphics[scale=0.4]{v6-v4-mixed}
+  \centering
+  \caption{In-network NAT64 translation}
+  \label{fig:v6v4mixed}
+\end{figure}
+
+
+allows our solution to be used as a standard NAT64
 translation method or as an in network NAT64 translation (compare
 figures \ref{fig:v6v4innetwork} and \ref{fig:v6v4standard}). The
 controller is implemented in python, the NAT64 solution is implemented
@@ -40,31 +139,19 @@ in P4. The network
 \end{figure}
 
 
-
 from intro:
 
-\begin{figure}[h]
-  \includegraphics[scale=0.4]{v6-v4-mixed}
-  \centering
-  \caption{Different network design with in network NAT64 translation}
-  \label{fig:v6v4mixed}
-\end{figure}
 
 
 Figures \ref{fig:v6v4standard} shows the standard NAT64
 approach and \ref{fig:v6v4innetwork} shows our solution.
-\begin{figure}[h]
-  \includegraphics[scale=0.7]{v6-v4-innetwork}
-  \centering
-  \caption{In Network NAT64 translation}
-  \label{fig:v6v4innetwork}
-\end{figure}
-\begin{figure}[h]
-  \includegraphics[scale=0.7]{v6-v4-standard}
-  \centering
-  \caption{Standard NAT64 translation}
-  \label{fig:v6v4standard}
-\end{figure}
+%% \begin{figure}[h]
+%%   \includegraphics[scale=0.6]{v6-v4-innetwork}
+%%   \centering
+%%   \caption{In Network NAT64 translation}
+%%   \label{fig:v6v4innetwork}
+%% \end{figure}
+
 
 
 Describe network layouts
diff --git a/doc/Thesis.pdf b/doc/Thesis.pdf
index 3773d83..8297186 100644
Binary files a/doc/Thesis.pdf and b/doc/Thesis.pdf differ
diff --git a/doc/appendix.tex b/doc/appendix.tex
index 02f6af6..3945ab5 100644
--- a/doc/appendix.tex
+++ b/doc/appendix.tex
@@ -2587,3 +2587,4 @@ Linux package management, handling updates, etc.
 \abbrev{NAT}{Network Address Translation}
 \abbrev{NAT64}{Network Address Translation from / to IPv6 to / from IPv4}
 \abbrev{RIR}{Regional Internet Registry}
+\abbrev{RTT}{Round Trip Time}