|
|
|
@ -103,22 +103,70 @@ the two protocols for this thesis are:
|
|
|
|
|
\label{fig:ipv4header} |
|
|
|
|
\end{figure} |
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
\section{\label{background:arpndp}ARP and NDP, ICMP ICMP6- FIXME} |
|
|
|
|
Required for finding host. |
|
|
|
|
ARP \cite{rfc826} who has |
|
|
|
|
NDP similar -- add traces here |
|
|
|
|
|
|
|
|
|
being able to answer to error messages |
|
|
|
|
MTU / pmtu |
|
|
|
|
|
|
|
|
|
Also add: IPv6 is closed / no arp |
|
|
|
|
ICMP6 \cite{rfc4443} |
|
|
|
|
%\LaTeX{} |
|
|
|
|
\section{\label{background:arpndp}ARP and NDP, ICMP and ICMP6} |
|
|
|
|
While IPv6 and IPv4 are primarily used as a ``shell'' to support |
|
|
|
|
addressing for protocols that have no or limited addressing support |
|
|
|
|
(like TCP or UDP), protocols like ARP \cite{rfc826} and NDP |
|
|
|
|
\cite{rfc4861} provide support for resolving IPv6 and IPv4 |
|
|
|
|
addresses to hardware (MAC) addresses. While both ARP and NDP are only |
|
|
|
|
used prior to establishing a connection on and their results are |
|
|
|
|
cached, their availability is crucial for operating a switch. |
|
|
|
|
Figure \ref{fig:arpndp} illustrates a typical address resolution process. |
|
|
|
|
\begin{figure}[h] |
|
|
|
|
\includegraphics[scale=0.3]{arp-ndp} |
|
|
|
|
\centering |
|
|
|
|
\caption{ARP and NDP} |
|
|
|
|
\label{fig:arpndp} |
|
|
|
|
\end{figure} |
|
|
|
|
The major difference between ARP and NDP in relation to P4 are |
|
|
|
|
\begin{itemize} |
|
|
|
|
\item ARP is a separate protocol on the same layer as IPv6 and IPv4, |
|
|
|
|
\item NDP operates below ICMP6 which operates below IPv6, |
|
|
|
|
\item NDP contains checksums over payload, |
|
|
|
|
\item and NDP in ICMP6 contains optional, non referenced option fields |
|
|
|
|
(specifically: ICMP6 link layer address option). |
|
|
|
|
\end{itemize} |
|
|
|
|
ARP is required to be a separate protocol, because IPv4 hosts don't |
|
|
|
|
know how to communicate with each other yet, because they don't have a |
|
|
|
|
way to communicate to the target IPv4 address (``The chicken and the |
|
|
|
|
egg problem''). |
|
|
|
|
NDP on the other hand already works within IPv6, as every IPv6 host is |
|
|
|
|
required to have a self-assigned link local IPv6 address from the |
|
|
|
|
range \texttt{fe80::/10} (compare RFC4291\cite{rfc4291}). NDP also |
|
|
|
|
does not require broadcast communication, because hosts automatically |
|
|
|
|
join multicast groups that embed parts of their |
|
|
|
|
IPv6 addresses (\cite{rfc2710}, \cite{wikipedia:_solic}). This way the |
|
|
|
|
collision domain is significantly reduced in IPv6, compared to IPv4. |
|
|
|
|
|
|
|
|
|
DNS64 \cite{rfc6174} |
|
|
|
|
As seen later in this document (compare |
|
|
|
|
\ref{results:netpfga:checksum}), the requirement to generate checksums |
|
|
|
|
over payload poses difficult problems for some hardware targets. Even |
|
|
|
|
more difficult is the use of options within ICMP6. Figure shows a |
|
|
|
|
typical layout of a neighbor advertisement messages. |
|
|
|
|
\begin{figure}[h] |
|
|
|
|
\includegraphics[scale=0.3]{icmp6ndp} |
|
|
|
|
\centering |
|
|
|
|
\caption{ICMP6 option fields} |
|
|
|
|
\label{fig:icmp6ndp} |
|
|
|
|
\end{figure} |
|
|
|
|
The problem arises from the layout of the options, as seen in the |
|
|
|
|
following quote: |
|
|
|
|
\begin{quote} |
|
|
|
|
Neighbor Discovery messages include zero or more options, some of |
|
|
|
|
which may appear multiple times in the same message. Options should |
|
|
|
|
be padded when necessary to ensure that they end on their natural |
|
|
|
|
64-bit boundaries.\footnote{From RFC4861.} |
|
|
|
|
\end{quote} |
|
|
|
|
|
|
|
|
|
IPv6 only network experiences \cite{rfc6586} |
|
|
|
|
Solicited-node multicast address\cite{wikipedia:_solic}. |
|
|
|
|
ICMP6 and ICMP are primarily used to signal errors in |
|
|
|
|
communication. Specifically signalling that a packet is too big to |
|
|
|
|
pass a certain link and needs fragmentation is a common functionality |
|
|
|
|
of both protocols. For a host (or switch) to be able to emit ICMP6 and |
|
|
|
|
ICMP messages, the host requires a valid IPv6 / IPv4 address. |
|
|
|
|
Without ICMP6 / ICMP support path mtu discovery (\cite{rfc1191}, |
|
|
|
|
\cite{rfc8201}) does not work and the sender needs to determine |
|
|
|
|
different ways of finding out the maximum MTU on the path. |
|
|
|
|
% ok -- need to separate backgroun and results |
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
\section{\label{background:transition}IPv6 Translation Mechanisms} |
|
|
|
|
While in this thesis the focus was in NAT64 as a translation mechanism, |
|
|
|
@ -185,6 +233,10 @@ information to choose from for translation, complex parsers or even
|
|
|
|
|
cryptographic methods are required for it. That reduces the |
|
|
|
|
opportunities of protocol dependent translation |
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
\subsection{\label{background:transition:dns64}DNS64 - FIXME} |
|
|
|
|
|
|
|
|
|
DNS64 \cite{rfc6174} |
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
\subsection{\label{background:transition:prefixnat}Prefix based NAT - |
|
|
|
|
FIXME} |
|
|
|
|
Explain how it works in general |
|
|
|
|