1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
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}
|
