From 6d38c3475eefc572600161316c788132a1f04465 Mon Sep 17 00:00:00 2001
From: Camil Staps
Date: Sun, 8 May 2016 22:46:20 +0200
Subject: Assignment 6

---
 assignment6.tex | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 115 insertions(+)
 create mode 100644 assignment6.tex

(limited to 'assignment6.tex')

diff --git a/assignment6.tex b/assignment6.tex
new file mode 100644
index 0000000..1e755d1
--- /dev/null
+++ b/assignment6.tex
@@ -0,0 +1,115 @@
+\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}
+
-- 
cgit v1.2.3

