\documentclass{ictlab}
%\errorcontextlines=99

\RCS $Revision: 1.4 $

\usepackage{verbatim,key,alltt,amstext,amsmath,answer2}
\usepackage[hang,bf,nooneline]{caption2}
\usepackage[pdfpagemode=None,pdfauthor={Nick Urbanik}]{hyperref}
%\renewcommand*{\subject}{Workshop Series}
\newcommand*{\labTitle}{%
  DHCP and \texttt{tcpdump}}
\providecommand*{\BGP}{\acro{BGP}\xspace}
\providecommand*{\IOS}{\acro{IOS}\xspace}
\providecommand*{\KDE}{\acro{KDE}\xspace}
\providecommand*{\VTI}{\acro{VTI}\xspace}
\providecommand*{\NETBIOS}{\acro{NETBIOS}\xspace}

 
\begin{document}
%\Large

\section{Background}
\label{sec:background}

The format of \DHCP packets was established with \RFC 951 for the
\emph{bootstrap protocol}, or \emph{bootp}.  \DHCP was made to be
backwardly compatible with the bootp protocol so that the
infrastructure of bootp relay agents on routers would not need to be
replaced.  The \DHCP extensions to bootp are bootp \emph{options}.
Figure~\vref{fig:dhcp-fixed-fields} shows the arrangement of the
fields in the \DHCP message, while
table~\vref{tab:message-fields} gives a description of each one.

See \emph{The DHCP Handbook} (Second Edition), Ralph Droms and Ted
Lemon, Sams, October 2002.  A copy is available in the library Reserved
Collection for a one day loan period, call number TK 5105.585 .D766
2003.  There is also a second copy on the shelves.  Also \RFC 2131 and 2132
are quite well written, and are quite easy to read.

 \begin{figure}[htb]
   \setlength{\extrarowheight}{2pt}
   \centering
   \begin{tabularx}{0.5\linewidth}[t]{|C|C|C|C|}
   %\begin{tabular}[t]{|p{2cm}|p{2cm}|p{2cm}|p{2cm}|}
   %\begin{tabular}[t]{|c|c|c|c|}
     \multicolumn{1}{c}{0  \hfill 7}  &
     \multicolumn{1}{c}{8  \hfill 15} &
     \multicolumn{1}{c}{16 \hfill 23} &
     \multicolumn{1}{c}{24 \hfill 31} \\
     \hline%
     op & htype & hlen & hops \\
     \hline%
     \multicolumn{4}{|c|}{xid} \\
     \hline%
     \multicolumn{2}{|c|}{secs} &
     \multicolumn{2}{c|}{flags}  \\
     \hline%
     \multicolumn{4}{|c|}{ciaddr}   \\
     \hline%
     \multicolumn{4}{|c|}{yiaddr}   \\
     \hline%
     \multicolumn{4}{|c|}{siaddr} \\
     \hline%
     \multicolumn{4}{|c|}{giaddr} \\
     \hline%
     \multicolumn{4}{|c|}{chaddr (16 bytes)} \\
     \hline%
     \multicolumn{4}{|c|}{sname (64 bytes)} \\
     \hline%
     \multicolumn{4}{|c|}{file (128 bytes)} \\
     \hline%
     \multicolumn{4}{|c|}{options (variable size)} \\
     \hline%
   \end{tabularx}
   \caption{The fields in the fixed-format section of a \DHCP message.}
   \label{fig:dhcp-fixed-fields}
 \end{figure}

\begin{table}[htb]
  %\large
  \begin{tabularx}{\linewidth}[t]{@{}>{\ttfamily}lY@{}}
    \toprule%
    \textnormal{\textbf{Field}} & \textbf{Description}\\
    \midrule%
    op & Message operation code: 1 in message from client, 2 in
    message from server\\
    htype & Link-layer address type from \RFC 1700.  For Ethernet,
    \texttt{htype} is 1.\\
    hlen & Link-layer address length, in bytes. (number of bytes in
    \texttt{chaddr} field)\\
    hops & Number of relay agents that have forwarded this message.\\
    xid & \emph{Transaction identifier}; used by clients to match responses
    from servers with previously transmitted requests. \\
    secs & Number of seconds since client began \DHCP transaction \\
    flags & Least significant bit is set to 1 to indicate messages to
    client must be broadcast \\
    ciaddr & Client's \IP address, set by client after reaches
    \texttt{BOUND} state (i.e., address is valid)\\
    yiaddr & Client's \IP address, set by server to inform client of
    its address (``your'' \IP address)\\
    siaddr & \IP address of the next server for the client to use
    (i.e., for the client to download an operating system kernel using
    \texttt{tftp}) \\
    giaddr & Relay agent (or ``gateway'') \IP address: relay agent
    fills this in with the address of the interface through which it
    received the \DHCP message\\
    chaddr & Client's link layer address (i.e., on our \LAN, the
    Ethernet address) \\
    sname & Name of the next server for client to use in the
    configuration process \\
    file & filename the client should request from the next server
    (i.e., an operating system kernel, or kickstart file)\\
    \bottomrule
  \end{tabularx}
  \caption{\DHCP Message fields; see
    figure~\vref{fig:dhcp-fixed-fields} for the arrangement of these
    fields in a \DHCP message.}
  \label{tab:message-fields}
\end{table}

\section{\texttt{tcpdump} and DHCP}
\label{sec:tcpdump-dhcp}

The manual page for the current version of \texttt{tcpdump} (version
3.7.1; an \RPM is available from our server) unfortunately does not
explain the detail of all the fields in the \DHCP protocol.  To
understand them all, it is necessary to look at the source.  Here is
my summary after reading \texttt{$\sim$/RPM/\allowbreak
  BUILD/\allowbreak tcpdump-3.7.1/\allowbreak
  tcpdump-3.7.1/\allowbreak print-bootp.c}.  I have put a copy of this
source file on the subject site.


Table~\vref{tab:tcpdump-dhcp-manual-fixed} shows how \texttt{tcpdump}
displays the \DHCP fields listed in table~\vref{tab:message-fields}.
Table~\vref{tab:tcpdump-dhcp-manual} shows how \texttt{tcpdump} shows
the \DHCP options.  Note that many of these are essential for \DHCP,
for example, the \DHCP message type, which is optional only for the
old bootp protocol.

Some other information will be provided by \texttt{tcpdump} that is
not directly concerned with \DHCP: for example, a packet with the \IP
don't fragment flag is marked with a trailing \texttt{(DF)}.

%Note that \texttt{tcpdump} flags each message with the following names

\begin{table}[htb]
  %\Large
  \begin{tabularx}{\linewidth}[t]{@{}>{\ttfamily}l>{\ttfamily}lY@{}}
    \toprule%
    \textnormal{\textbf{Field}} &
    \textnormal{\textbf{Format in \texttt{tcpdump}}} & \textbf{Short Description} \\
    \midrule%
    htype & htype-\#\meta{length} & length of link-layer address, bytes \\
    hops & hops:\meta{hops} & number of relay agents  \\
    xid & xid:0x\meta{32-bit hex ID}  & transaction \ID \\
    secs & secs:\meta{seconds} & seconds since session started \\
    flags & flags:0x\meta{hex digits} & \LSb is broadcast flag \\
    ciaddr & C:\meta{IP address} & Client's \IP address  \\
    yiaddr & Y:\meta{IP address} & `your' \IP address (bootp client) \\
    siaddr & S:\meta{IP address} & Server's \IP address  \\
    giaddr & G:\meta{IP address} & Gateway's \IP address \\
    chaddr & ether \meta{MAC address} & Ethernet address \\
    sname & sname "\meta{servername}" & name of next server \\
    file & file "\meta{filename}" & file name to download \\
    \bottomrule%
  \end{tabularx}
  \caption{How tcpdump represents some of the fixed \DHCP fields.  See
    table~\vref{tab:message-fields} for more details of each field.}
  \label{tab:tcpdump-dhcp-manual-fixed}
\end{table}


\begin{table}[htb]
  %\Large
  \begin{tabularx}{\linewidth}[t]{@{}>{\ttfamily}lY@{}}
    \toprule%
    \textnormal{\textbf{Format in \texttt{tcpdump}}} & \textbf{Short Description} \\
    \midrule%
    SM:\meta{dotted quad IP} & Subnet mask (as an \IP address) \\
    CID:\meta{client ID} & Client \ID; may be an Ethernet address, or
    an identifier string provided by client.  Examples:
    \texttt{CID:"cisco-0008.e3aa.3ac0-VL1"[len 25]} and one with an
    Ethernet client \ID: \texttt{CID:[ether]00:08:02:40:4e:c5} \\
    SID:\meta{name or IP} & Server \ID \\
    DG:\meta{name or IP} & Default gateway, \IP address \\
    %TS & Time server, \IP address \\
    NTP:\meta{name or IP} & Network Time Protocol server, \IP address \\
    NS:\meta{server},\ldots & Name servers, \IP addresses  \\
    HN:"\meta{host name}" & Host name \\
    DN:"\meta{domain name}" & Domain name \\
    VC:"\meta{class}" & Vendor Class (variable length \ASCII string).
    Some examples: \texttt{VC:"Linux 2.4.18-3 i686"},
    \texttt{VC:"Linux 2.4.18-6mdk i686"}, \texttt{VC:"MSFT 98"},
    \texttt{VC:"MSFT 5.0"},
    \texttt{VC:"Hewlett-Packard JetDirect"} \\
    PR:\meta{option}+\meta{option}\ldots & Parameter Request---for the
    parameters that are listed in the
    request \\
    WNS:\meta{name or IP},\ldots & \WINS (\NETBIOS) name server, \IP address \\
    WNT & \NETBIOS node \\
    WSC & \NETBIOS scope, \ASCII string \\
    RD & Perform Router Discovery, binary value\\
    SR & Static Route, a list of \IP address pairs: address of
    destination, address of router.  But useless in \CIDR \\
    VO & Vendor Options --- period-separated decimal bytes (variable length)\\
    MSZ:\meta{integer} & Maximum Message size (16 bit short integer)\\
    FQDN & Fully-qualified domain name; a request from client to
    server to use a particular \acro{FQDN}.  Server only responds to
    this, and does not send unless requested by client.  Format is:
    first byte is flags, used to indicate state of negotiation.
    Actual name begins at the fourth byte. \\
    LT:\meta{seconds} & Lease time \\
    RN:\meta{seconds} & Renewal time  ($T1$)\\
    RB:\meta{seconds} & Rebinding time ($T2$) \\
    \bottomrule%
  \end{tabularx}
  \caption{How tcpdump represents various \DHCP options.}
  \label{tab:tcpdump-dhcp-manual}
\end{table}

\begin{figure}[htbp]
  \centering%
  %\includegraphics[scale=0.5]{dhcp-client-state-diagram-cropped}
  \includegraphics[width=0.82\linewidth]{dhcp-client-state-diagram}
  \caption{A state diagram showing states of a \DHCP client.  Note
    that $T$ is the lease time, $T\mathit{1} = \frac{T}{2}$,
    $T\mathit{2} = \frac{7T}{8}$.  See also
    table~\vref{tab:dhcp-messages} from the \DHCP \RFC 2131
    (available in full at
    \texttt{/home\allowbreak/nfs\allowbreak/ietf\allowbreak
      /rcf\allowbreak/rfc2131\allowbreak.txt}), which sumarises
    \DHCP messages.}
  \label{fig:dhcp-client-state-diagram}
\end{figure}

  \begin{table}[htbp]
    %\scriptsize
    \begin{tabularx}{\linewidth}[t]{@{}>{\ttfamily}l@{\hspace{2ex}---\hspace{2ex}}Y>{\ttfamily}l@{}}
\toprule%
\multicolumn{1}{@{}l}{\textbf{Message}} & \textbf{Use} & \textbf{\texttt{tcpdump}}\\
\midrule%
   DHCPDISCOVER &  Client broadcast to locate available servers.
                &  DHCP:DISCOVER\\
%
   DHCPOFFER    &  Server to client in response to \texttt{DHCPDISCOVER} with
                   offer of configuration parameters. & DHCP:OFFER\\
%
   DHCPREQUEST  &  Client message to servers either (a) requesting
                   offered parameters from one server and implicitly
                   declining offers from all others, (b) confirming
                   correctness of previously allocated address after,
                   e.g., system reboot, or (c) extending the lease on a
                   particular network address. & DHCP:REQUEST\\
%
   DHCPACK      &  Server to client with configuration parameters,
                   including committed network address. & DHCP:ACK\\
%
   DHCPNAK      &  Server to client indicating client's notion of network
                   address is incorrect (e.g., client has moved to new
                   subnet) or client's lease as expired & DHCP:NACK \\
%
   DHCPDECLINE  &  Client to server indicating network address is already
                   in use. & DHCP:DECLINE \\
%
   DHCPRELEASE  &  Client to server relinquishing network address and
                   cancelling remaining lease. & DHCP:RELEASE\\
%
   DHCPINFORM   &  Client to server, asking only for local configuration
                   parameters; client already has externally configured
                   network address. & DHCP:INFORM \\
                   \bottomrule%
    \end{tabularx}
    \caption{DHCP Messages: this is ``table 2'' from \RFC 2131; the
      \RFC is available in full from \texttt{ictlab} at
      \texttt{/home\allowbreak
        /nfs\allowbreak
        /ietf\allowbreak/rcf\allowbreak/rfc2131\allowbreak.txt}.}
    \label{tab:dhcp-messages}
  \end{table}
\end{document}
