\documentclass[a4paper,9pt]{article}

\author{Camil Staps\\\small{s4498062}}
\title{Networking\\\large{Assignment 7}}
\date{May 22, 2016}

\usepackage{polyglossia}
\setmainlanguage{english}
\usepackage{geometry}
\usepackage[hidelinks]{hyperref}
\usepackage{amsmath}
\usepackage{enumitem}
\usepackage{subcaption}
\usepackage{verbatimbox}

\begin{document}

\maketitle

\section{Cyclic Redundancy Checks}
\begin{enumerate}[label=\alph*)]
	\item It computes the remainder of $(D\cdot2^r\oplus R) \div G$, and checks
		that it equals $0$.
	\item See \autoref{fig:longdiv:b}. The answer is \texttt{111}.
	\item See \autoref{fig:longdiv:c}. The answer is \texttt{010}.
	\item See \autoref{fig:longdiv:d}. The answer is \texttt{111}.
\end{enumerate}

\begin{figure}[h]
	\small
	\begin{subfigure}[b]{.32\linewidth}
		\centering
		\begin{verbbox}
			1001010101 000
			1001
			0000010101 000
			     1001
			0000000111 000
			       100 1
			0000000011 100
			        10 01
			0000000001 110
			         1 001
			0000000000 111
		\end{verbbox}
		\theverbbox%
		\caption{\label{fig:longdiv:b}}
	\end{subfigure}
	\begin{subfigure}[b]{.32\linewidth}
		\centering
		\begin{verbbox}
			0101101010 000
			 1001
			0001001010 000
			   1001
			0000000010 000
			        10 01
			0000000000 010
		\end{verbbox}
		\theverbbox%
		\caption{\label{fig:longdiv:c}}
	\end{subfigure}
	\begin{subfigure}[b]{.32\linewidth}
		\centering
		\begin{verbbox}
			1010100000 000
			1001
			0011100000 000
			  1001
			0001110000 000
			   1001
			0000111000 000
			    1001
			0000011100 000
			     1001
			0000001110 000
			      1001
			0000000111 000
			       100 1
			0000000011 100
			        10 01
			0000000001 110
			         1 001
			0000000000 111
		\end{verbbox}
		\theverbbox%
		\caption{\label{fig:longdiv:d}}
	\end{subfigure}
	\caption{Computing CRC using long division\label{fig:longdiv}}
\end{figure}

\section{Address Resolution Protocol}
\begin{enumerate}
	\item We call the left router R and the right router S. Let $R_i$ be the
		interface of router $R$ for subnet $i$. Then:

			A --- 192.168.1.100; B --- 192.168.1.200;\\
			C --- 192.168.2.100; D --- 192.168.2.200;\\
			E --- 192.168.3.100; F --- 192.168.3.200;\\
			R$_1$ --- 192.168.1.1; R$_2$ --- 192.168.2.1;\\
			S$_2$ --- 192.168.2.2; S$_3$ --- 192.168.3.2;\\

	\item
		A --- 00.00.00.00.00.A0; B --- 00.00.00.00.00.B0;\\
		C --- 00.00.00.00.00.C0; D --- 00.00.00.00.00.D0;\\
		E --- 00.00.00.00.00.E0; F --- 00.00.00.00.00.F0;\\
		R$_1$ --- 88.88.88.00.00.00; R$_2$ --- 88.88.88.00.88.00;\\
		S$_2$ --- 88.88.88.88.00.00; S$_3$ --- 88.88.88.88.88.00.

	\item Host E looks up the MAC address of the first hop router (S$_3$), and
		sends the datagram there. Router S receives the datagram, figures out that
		the next hop is router R, looks up the MAC address of R$_2$ and sends the
		datagram there. Router R then forwards the datagram in a frame to host B on
		interface R$_1$. Concretely, the following frames are sent:

		\begin{table}[h]
			\centering
			\begin{tabular}{l l l l}
				Src. IP       & Src. MAC          & Dest. IP      & Dest. MAC \\\hline
				192.168.3.100 & 00.00.00.00.00.E0 & 192.168.3.2   & 88.88.88.88.88.00\\
				192.168.2.2   & 88.88.88.88.88.00 & 192.168.2.1   & 88.88.88.00.88.00\\
				192.168.1.1   & 88.88.88.00.88.00 & 192.168.1.200 & 00.00.00.00.00.B0\\
			\end{tabular}
		\end{table}

	\item The same happens, but before E can send the frame to S$_3$, it has to
		get to know its address. It sends an ARP request to the broadcast address
		with the request for 192.168.3.2's (that is, S$_3$'s) MAC address. The
		router replies with an ARP packet. After this, E has all the addresses it
		needs (and all other nodes as well), so the same as above happens.

		\begin{table}[h]
			\centering
			\begin{tabular}{l l l l l}
				Src. IP       & Src. MAC          & Dest. IP      & Dest. MAC         & Protocol\\\hline
				192.168.3.100 & 00.00.00.00.00.E0 & 192.168.3.2   & FF.FF.FF.FF.FF.FF & ARP\\
				192.168.3.2   & 88.88.88.88.88.00 & 192.168.3.100 & 00.00.00.00.00.E0 & ARP\\
				192.168.3.100 & 00.00.00.00.00.E0 & 192.168.3.2   & 88.88.88.88.88.00 & IP\\
				192.168.2.2   & 88.88.88.88.88.00 & 192.168.2.1   & 88.88.88.00.88.00 & IP\\
				192.168.1.1   & 88.88.88.00.88.00 & 192.168.1.200 & 00.00.00.00.00.B0 & IP\\
			\end{tabular}
		\end{table}
\end{enumerate}

\section{Self-learning}
\begin{enumerate}[label=(\roman*)]
	\item The switch learns the MAC address of host B. Since it doesn't know
		where host E is, it forwards the frame to all links (except the one of B).
	\item The switch learns the MAC address of host E. Since it knows where host
		B is, it forwards the frame only to that host.
	\item The switch learns the MAC address of host A. Since it knows where host
		B is, it forwards the frame only to that host.
	\item The switch knows where host A is, it forwards the frame only to that
		host.
\end{enumerate}

\section{All things learned put together}
\begin{enumerate}
	\item We need an IP address. We will use DHCP for this. We create a DHCP
		request message (stack: DHCP, UDP, IP, Ethernet). We sent this from port 68
		to 67, with source IP 0.0.0.0 (we don't have an IP yet) to the broadcast IP
		address (255.255.255.255, because we don't know the DHCP server's IP
		address). On the link layer, we send from our MAC to the broadcast address
		FF:FF:FF:FF:FF:FF.
	\item If there are switches in between us and the DHCP server, they forward
		this to everywhere because of the broadcast address.
	\item The DHCP server (we'll assume this is the router and the gateway as
		well) receives the frame with the broadcast address, reads the IP datagram
		with the broadcast address, reads the UDP packet, and finally the DHCP
		server process reads the DHCP packet and responds to it with a DHCP ACK
		message. This contains the DHCP server's IP, and the assigned IP. This
		traverses down the layers and is sent back to the client. The switches have
		now learned our MAC address and don't broadcast this.
	\item We can now save our IP, the DHCP server's IP and also the DNS servers
		suggested. We will now use that DHCP server as the default gateway.
	\item In the next step we'll need the gateway's MAC address. We do this with
		ARP. We send an ARP query with as target IP the gateway's IP, source IP our
		IP, source MAC our MAC, and destination MAC the broadcast address
		FF:FF:FF:FF:FF:FF. Switches relay this to all nodes as above. The gateway,
		recognising its IP, will reply with an ARP reply. This reply has as source
		MAC and IP the addresses of the gateway and as destination MAC and IP the
		addresses of our host. The switches relay this back to us.
	\item Suppose we want to access www.google.nl. We then need to lookup the IP
		address for that host using DNS. We send a DNS query for the A record of
		www.google.nl to the DNS server advertised by the DHCP server (say
		8.8.8.8). We thus send a UDP segment to 8.8.8.8:53 requesting the IP
		address of www.google.nl. We send this datagram to the default gateway,
		which forwards it into the internet (through different routers, using
		different routing protocols, possibly using inter-AS routing, etc.). In the
		end, we receive a reply containing that IP address.

		In dns.pcap, we see two requests being made: one for A records and one for
		AAAA records. We thus receive both IPv4 and IPv6 addresses for
		www.google.nl. The first response lists several IPs. For IPv4, for example,
		64.15.117.26 but also 64.15.117.24.

		See \autoref{fig:dns} or dns.pcap.
	\item We then create an HTTP GET request for www.google.nl. We put this in a
		TCP package with source IP our IP, destination IP the IP for www.google.nl
		just received, and destination port 80. This is sent to the gateway router,
		which manages to forward it to the Google servers (as above to 8.8.8.8).
		The Google server receives the request, parses and handles it, and crafts
		an HTTP response which is encapsulated in another TCP packet. This packet
		has as destination IP and port the source IP and port of the request, and
		vice versa. It is sent to the destination IP through routers, and
		eventually gets received by our host. Our host then handles the reply (for
		example, in a browser, by drawing a graphical representation of the HTML in
		the response and making additional requests for images, JS, CSS, etc.).

		In reality, we're using HTTPS, so we can't follow the HTTP stream. However,
		we do see (in https.pcap) that requests are being made to the address we
		found in the previous step (64.15.117.26). We now use port 443 because of
		HTTPS. Generally, some packets will hold the initial request and reply. The
		request takes up one packet, the reply four. After that, the browser reads
		the HTML and sees it needs some pictures, JavaScript scripts and style
		sheets. It then sends many more requests.

		See \autoref{fig:https} or https.pcap.
\end{enumerate}

If our router uses NAT, it will rewrite addresses and ports in a fashion
described in an earlier exercise.

\begin{figure}[h]
	\includegraphics[width=\linewidth]{assignment7/dns}
	\caption{DNS capture\label{fig:dns}}
\end{figure}

\begin{figure}[h]
	\includegraphics[width=\linewidth]{assignment7/https}
	\caption{HTTPS capture\label{fig:https}}
\end{figure}

\end{document}
