\documentclass[a4paper,9pt]{article}

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

\usepackage{polyglossia}
\setmainlanguage{english}
\usepackage{geometry}
\usepackage{amsmath}
\usepackage{enumitem}
\usepackage{minted}

\begin{document}

\maketitle

\section{IP Fragmentation}
\begin{enumerate}
	\item The necessary IP headers add 20 bytes overhead, so we can send
		$700-20=680$ bytes per fragment. Then we need
		$\left\lceil\frac{2400}{680}\right\rceil=4$ fragments.
	\item Length, fragmentation flag, fragmentation offset, identifier.
	\item
		\begin{tabular}{l | l | l | l}
			Length & ID & Frag. flag & Frag. offset \\\hline
			700   & 422 & 1          & 0            \\
			700   & 422 & 1          & 85           \\
			700   & 422 & 1          & 170          \\
			380   & 422 & 0          & 255          \\
		\end{tabular}
\end{enumerate}

\section{Distance vector}
\begin{enumerate}
	\item $\{\text{w}\mapsto2, \text{y}\mapsto5, \text{u}\mapsto7\}$.
	\item $c(x,w) \leftarrow 1$.
	\item $c(x,y) \leftarrow 4$.
\end{enumerate}

\section{Inter-AS routing with BGP}
\begin{enumerate}
	\item
		To B: (i) for network W, AS-Path A, some next hop; (ii) for network V,
		AS-Path A, some next hop. \\
		To C: for network V, AS-Path A, some next hop.
	\item
		From A: for network V, AS-Path A, some next hop. \\
		From B: (i) for network X, AS-Path B, some next hop; (ii) for network W,
		AS-Path B-A, some next hop; (iii) for network V, AS-Path B-A, some next
		hop.
\end{enumerate}

\clearpage
\section{DHCP Wireshark}
\bgroup\footnotesize\begin{verbatim}
34  192.168.1.70  192.168.1.1      DHCP  342  DHCP Release  - Transaction ID 0xbff3c458
37  0.0.0.0       255.255.255.255  DHCP  342  DHCP Discover - Transaction ID 0x19a9e831
38  192.168.1.1   192.168.1.70     DHCP  316  DHCP Offer    - Transaction ID 0x19a9e831
39  0.0.0.0       255.255.255.255  DHCP  342  DHCP Request  - Transaction ID 0x19a9e831
40  192.168.1.1   192.168.1.70     DHCP  316  DHCP ACK      - Transaction ID 0x19a9e831
75  192.168.1.70  192.168.1.1      DHCP  342  DHCP Release  - Transaction ID 0x3cb8ec3a
79  0.0.0.0       255.255.255.255  DHCP  342  DHCP Discover - Transaction ID 0x26644c66
84  192.168.1.1   192.168.1.70     DHCP  316  DHCP Offer    - Transaction ID 0x26644c66
85  0.0.0.0       255.255.255.255  DHCP  342  DHCP Request  - Transaction ID 0x26644c66
86  192.168.1.1   192.168.1.70     DHCP  316  DHCP ACK      - Transaction ID 0x26644c66
\end{verbatim}\egroup

\begin{enumerate}[label=\alph*)]
	\item \texttt{60:57:18:b1:e8:8d}; bytes 6-11 of the first packet.
	\item Of course, the DHCP message type has been changed from discover to
		request. Also, option 54 (Server Identifier) has been added.
	\item This option has the value \texttt{192.168.1.1}.
	\item 1 day (86400s); found in the end of packet 40.
	\item The client uses port \texttt{68}; the server \texttt{67}. The client
		requests and gets \texttt{192.168.1.70}; the server uses
		\texttt{192.168.1.1}. Before the client receives its IP and knows the IP of
		the DHCP server, it sends broadcasts from \texttt{0.0.0.0} to
		\texttt{255.255.255.255}.
	\item \texttt{0x19a9e831}; \texttt{0x26644c66}. The purpose of this field is
		`to associate messages and responses between a client and a server' (RFC
		2131). This is necessary because we need to maintain a state. The client
		should know what request is being answered to when it receives a response.
	\item The server does not acknowledge the release. It is strictly speaking
		not necessary (to explicitly release), however, can be useful to prevent
		denial of service: since the subnet here is \texttt{255.255.255.0} we have
		only 255 addresses to give out. If addresses were never released, it could
		easily happen that all addresses are used (if some client has a problem and
		requests new addresses all the time). In any case, releasing addresses
		should be seen as a service clients may/should provide the server with.
	\item
		\bgroup\footnotesize\begin{verbatim}
46	IntelCor_b1:e8:8d	Broadcast	ARP	42	Who has 192.168.1.1?  Tell 192.168.1.70
47	ZyxelCom_c5:63:e1	IntelCor_b1:e8:8d	ARP	42	192.168.1.1 is at 4c:9e:ff:c5:63:e1
		\end{verbatim}\egroup

		(There are some other ARP packets in the capture, but they are from an
		unrelated host.)

		This is after the DHCP ACK. It seems superfluous, because the DHCP ACK is
		coming from \texttt{192.168.1.1}, so the client could get the information
		it requests in packet 46 from packet 40. Therefore, this packet is probably
		sent from a different layer or program. I'm guessing it has to do with
		\texttt{192.168.1.1} being advertised as router and/or DNS server. The
		client receives this information on another level than where it makes the
		DHCP requests, and therefore doesn't recognise that it already received the
		information implicitly. It then uses ARP to find the link layer address of
		the DNS server and/or the router that is advertised in the ACK.
\end{enumerate}

Note: for privacy reasons, I only provide captures of the bootstrap and ARP
protocols.

\end{document}

