diff options
Diffstat (limited to 'assignment6.tex')
| -rw-r--r-- | assignment6.tex | 115 |
1 files changed, 115 insertions, 0 deletions
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} + |