.. _AppBroadcast:

.. raw:: html

   <script>ODSA.SETTINGS.DISP_MOD_COMP = true;ODSA.SETTINGS.MODULE_NAME = "AppBroadcast";ODSA.SETTINGS.MODULE_LONG_NAME = "Application-Layer Broadcasting: DHCP";ODSA.SETTINGS.MODULE_CHAPTER = "Networked Concurrency"; ODSA.SETTINGS.BUILD_DATE = "2021-06-01 12:51:47"; ODSA.SETTINGS.BUILD_CMAP = false;JSAV_OPTIONS['lang']='en';JSAV_EXERCISE_OPTIONS['code']='java';</script>


.. |--| unicode:: U+2013   .. en dash
.. |---| unicode:: U+2014  .. em dash, trimming surrounding whitespace
   :trim:


.. This file is part of the OpenCSF eTextbook project. It was
.. auto-generated by scripts from the OpenDSA eTextbook project.
.. See https://OpenCSF.org for more details. OpenCSF is distributed
.. under a Creative Commons Attribution-NonCommercial 4.0 International
.. License (see http://creativecommons.org/licenses/by-nc/4.0/),
.. Copyright (c) 2019-2021 by Michael S. Kirkpatrick. OpenDSA is
.. distributed under an MIT open source license, Copyright (c) 2012-2021
.. by the OpenDSA Project Contributors.

.. avmetadata::
   :author: Michael S. Kirkpatrick
   :requires:
   :satisfies: DHCP
   :topic: DHSP, Broadcast

Application-Layer Broadcasting: DHCP
====================================

DNS provides a mechanism that clients can use to determine the IP address for a server based on a
human-readable domain name. In addition, server processes for common protocols listen for incoming
requests on well-known ports. The client can use the address and port number to call ``connect()``
to establish a TCP connection for an HTTP request; for UDP services like DNS, the client uses the
address and port number when it calls ``sendto()`` to deliver the datagram. Thus, in both cases,
there are clear mechanisms for how the client determines the IP address and port number for the
server. This raises the question of how the server determines the corresponding information to send
the message back to the client.

One part of the answer to this question is that the TCP and UDP services provide this information
along with the request. As we will note in the next chapter, transport-layer protocols attach a
header to application-layer data containing the IP address and port numbers for both the sender and
the receiver. However, this answer is not fully satisfying, because it does not explain how the
client's IP address is set. (Explaining the port number is easy: For ephemeral ports, the OS picks a
random 16-bit number, typically above the value 4096.)

IP addresses can be either :term:`static <static IP address>` or :term:`dynamic <dynamic IP
address>`. With a static IP address, the ISP determines a constant value that gets persistently
associated for a particular device; the device is configured so that it uses the same IP address
every time it boots up. Static IP addresses are commonly used for servers; this practice reduces
strain on the DNS, which would have to be updated every time the IP address for a server changed.
For end-user client devices, such as laptops, tablets, mobile phones, or Internet-connected *smart
home* devices, IP addresses are normally determined by the :term:`Dynamic Host Configuration
Protocol` (DHCP), a protocol that assigns IP addresses dynamically when the device connects to a
network. Note that this protocol is used in both wireless and wired networks, as DHCP will also run
when a computer is connected via an Ethernet cable.

DHCP Overview
-------------

The specification for DHCP is defined in RFC 2131. The full protocol is significantly more complex
than either HTTP or DNS, because DHCP requires multiple steps rather than the basic request-response
structure. DHCP message exchanges can include negotiation back and forth between the client and
server based on the hardware and software requirements of each. Additionally, clients can abort the
request before the protocol completes, and the server would need to recognize when this happens and
close the connection to free up resources. Implementing the full specification requires building
state machines for both the client and server. In this section, though, we limit the discussion to
the most basic type of (successful) exchange because it illustrates a new socket programming
technique not discussed previously: :term:`broadcasting <broadcast>`.

.. _DHCPBroadcast:

.. figure:: Images/CSF-Images.4.13.png
   :align: right
   :width: 95%
   :figwidth: 45%
   :alt: Sequence of DHCP messages across a network

   Sequence of DHCP messages across a network

:num:`Figure #DHCPBroadcast` illustrates the sequence of messages across a network for a DHCP
request. To initiate a DHCP request, a new client (such as a laptop) uses UDP to broadcast a ``DHCP
discover`` message, which declares that the sender is trying to find a DHCP server. In other words,
the client sends a message using a reserved IP address that indicates the client does not know the
destination. If the client is connected to a router that is running a DHCP server, the router would
accept the message and would not forward it. However, if there is no intervening router (e.g., the
client is connected via an Ethernet cable), then the message is sent to all hosts on the local
network. Most devices on the network are not running DHCP servers, so they have no process listening
at the well-known DHCP port number (67). For instance, a connected smart TV or network-accessible
storage (NAS) hard drive would not be listening for incoming DHCP requests. For these devices, the
OS simply ignores the message.

When the broadcast message is received by a DHCP server, the server replies by broadcasting a ``DHCP
offer`` that informs the client of the server's IP address, as well as proposing an IP address for
the client to use. If there are multiple DHCP servers running on the network, then any that receives
the ``DHCP discover`` message will respond with a ``DHCP offer``. The client accepts the offer by
sending a ``DHCP request``. Although this message is broadcast, the body of the request contains
information to designate which DHCP server's offer is being accepted. That server confirms the
configuration to all devices by broadcasting a final ``DHCP ACK`` (acknowledgement) that declares
the new client has successfully been assigned to that particular IP address.


DHCP Protocol Messages
----------------------

.. _tbl4-10:

.. raw:: html

   <center>
   <div class="col-md-6">
   <table class="table table-bordered">
     <thead class="jmu-dark-purple-bg text-light">
       <tr>
         <th class="p-0 center" style="width: 25%">0-7</th>
         <th class="p-0 center" style="width: 25%">8-15</th>
         <th class="p-0 center" style="width: 25%">16-23</th>
         <th class="p-0 center" style="width: 25%">24-31</th>
       </tr>
     </thead>
     <tbody>
       <tr>
         <td class="py-0 center"><code>op</code></td>
         <td class="py-0 center"><code>htype</code></td>
         <td class="py-0 center"><code>hlen</code></td>
         <td class="py-0 center"><code>hops</code></td>
       </tr>
       <tr> <td class="py-0 center" colspan="4"><code>xid</code></td> </tr>
       <tr>
         <td class="py-0 center" colspan="2"><code>secs</code></td>
         <td class="py-0 center" colspan="2"><code>flags</code></td>
       </tr>
       <tr> <td class="py-0 center" colspan="4"><code>ciaddr</code></td> </tr>
       <tr> <td class="py-0 center" colspan="4"><code>yiaddr</code></td> </tr>
       <tr> <td class="py-0 center" colspan="4"><code>siaddr</code></td> </tr>
       <tr> <td class="py-0 center" colspan="4"><code>giaddr</code></td> </tr>
       <tr> <td class="py-0 center" colspan="4"><code>chaddr (16 bytes)</code></td> </tr>
       <tr> <td class="py-0 center" colspan="4"><code>sname (64 bytes)</code></td> </tr>
       <tr> <td class="py-0 center" colspan="4"><code>file (128 bytes)</code></td> </tr>
       <tr> <td class="py-0 center" colspan="4"><code>options (variable)</code></td> </tr>
       </tr>
     </tbody>
   </table>
   </div>
   <p>
   Table 4.10: Structure of a DHCP message
   </p>
   </center>


RFC 2131 defines the core structure of DHCP messages, which is shown in `Table 4.10 <#tbl4-10>`_. In
this illustration, each row of the table is 32 bits (four bytes) wide, and some fields would require
multiple rows, as they are larger than four bytes in size. While this structure shows the relative
ordering of the fields, the exact structure depends on the type of message. Depending on the type,
some fields may be required, others are optional, and still more are not allowed. RFC 2132 specifies
the allowable options.

For the four basic messages shown in :num:`Figure #DHCPBroadcast`, the important fields to consider
are ``op``, ``xid``, ``yiaddr``, and ``siaddr``. The ``op`` field can be set to either
``BOOTREQUEST`` (1) or ``BOOTREPLY`` (2), indicating if the message is coming from the client or the
server. As in DNS, the ``xid`` is a random integer to denote the transaction ID, connecting replies
with the specific requests. The ``yiaddr`` is used to indicate *your* (the client's) IP address,
while siaddr is the DHCP server's address. The other fields, described in the RFC, are beyond the
scope of this book. `Table 4.11 <#tbl4-11>`_ shows the values of these fields for a sample DHCP
request. All messages are sent to the destination IP address 255.255.255.255, which is the reserved
value that indicates a broadcast message. The client uses 0.0.0.0 as its source address for the UDP
messages, indicating the sending host has no valid address, while the DHCP server can use its own address. 

The client distinguishes itself from other new clients by picking a random value to use as the
``xid``, which is 42 for the ``DHCP discover`` message in this case; after the server replies with
the same ``xid`` value, the client increments it by one and the server repeats the value again. A
``DHCP discover`` message from another new client might have 587 for its ``xid``. By receiving a
broadcast message with ``xid`` 42 and 43 from the server, the client that started with 42 has
reasonable assurance that it is the intended recipient.

.. _tbl4-11:

.. raw:: html

   <center>
   <table class="table table-bordered">
     <thead class="jmu-dark-purple-bg text-light">
       <tr>
         <th class="py-0 center">Message type</th>
         <th class="py-0 center">UDP addressing</th>
         <th class="py-0 center">DHCP contents</th>
       </tr>
     </thead>

     <tbody>
       <tr>
         <td class="py-0"><code>DHCP discover</code></td>
         <td class="py-0"><code>SRC: 0.0.0.0:68<br />DEST: 255.255.255.255:67</code></td>
         <td class="py-0"><code>op: BOOTREQUEST<br />xid: 42<br />yiaddr: 0.0.0.0</code></td>
       </tr>

       <tr>
         <td class="py-0"><code>DHCP offer</code></td>
         <td class="py-0"><code>SRC: 192.168.1.1:67<br />DEST: 255.255.255.255:68</code></td>
         <td class="py-0"><code>op: BOOTREPLY<br />xid: 42<br />yiaddr: 192.168.1.7<br />siaddr: 192.168.1.1<br />lease time: 86400</code></td>
       </tr>

       <tr>
         <td class="py-0"><code>DHCP request</code></td>
         <td class="py-0"><code>SRC: 0.0.0.0:68<br />DEST: 255.255.255.255:67</code></td>
         <td class="py-0"><code>op: BOOTREQUEST<br />xid: 43<br />yiaddr: 192.168.1.7<br />siaddr: 192.168.1.1</code></td>
       </tr>

       <tr>
         <td class="py-0"><code>DHCP ACK</code></td>
         <td class="py-0"><code>SRC: 192.168.1.1:67<br />DEST: 255.255.255.255:68</code></td>
         <td class="py-0"><code>op: BOOTREPLY<br />xid: 43<br />yiaddr: 192.168.1.7<br />siaddr: 192.168.1.1<br />lease time: 86400</code></td>
       </tr>
     </tbody>
   </table>
   <p>
   Table: 4.11: Structure of DHCP messages to set up an IP address

   </p>
   </center>

The other fields in the DHCP message establish the new client's IP configuration. When the server
sends the ``DHCP offer``, the ``yiaddr`` field contains a proposed value for the client's address.
The client could reject the address, but here we assume that the offer is accepted. The client
indicates that it accepts the offer by using the same value in its ``DHCP request``, and the server
confirms the acceptance in the ``DHCP ACK``. In addition, these messages establish that the client
knows the IP address of the DHCP server (``siaddr``), along with the duration of the
*lease*\—the time during which the client owns this IP address. In this case, the client will
have a lease on the address 192.168.1.7 for a maximum of 86,400 seconds (24 hours). When the lease
expires, the client would contact the server to renew the lease. At that point, the client would not
need to repeat the full protocol; since the client knows the IP address of the server, it does not
need to begin back at the ``DHCP discover`` stage.

.. avembed:: Exercises/Sockets/BroadcastSumm.html ka
   :module: AppBroadcast
   :points: 1.0
   :required: True
   :exer_opts: JXOP-debug=true&amp;JOP-lang=en&amp;JXOP-code=java
   :long_name: Socket broadcasting questions
   :threshold: 4