\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}