Dynamic Host Configuration Protocol
Mississippi College
Computer Science
Dr. Bennet
  1. Dynamic Host Configuration Protocol
    1. When a computer connects to the network, it must find its IP address, router, name server and so forth. DHCP tells it.
    2. Once a system makes a physical or radio connection to the network, it sends a message to the limited broadcast address 255.255.255.255 to find out who it is.
    3. Exchange continues from there, using real addresses as soon as possible.
    4. DHCP messages use the UDP transport protocol, which we haven't talked about yet, but here's how it encapsulates:
      DHCP Message
      UDP Header
      UDP Payload
      IP Header
      IP Payload (ICMP message)
      Frame Header
      Frame Payload (IP datagram)
      1. The Ethernet frame type is 0800 hex for Internet.
      2. The Type field in the IP header contains 17 for UDP.
      3. The UDP header does not have a type, but uses DHCP ports, 67 or 68, depending on the direction, client-to-server or server-to-client.
  2. Message Format.
    1. The protocol evolved from the earlier BOOTP protocol.
      1. In the good old days, things like IP addresses were configured by hand on each of the very few machines that needed one.
      2. Then we invented the PC, and the administrators typing fingers got tired, so we needed an automatic solution.
      3. A PC sitting on a desk or table needs its network configuration when it starts up, hence the name BOOTP.
      4. As portable devices and wireless evolved, the protocol needed to do more, and needed to do it at any network connection, which need not be at boot time.
      5. The message format was not changed, but some of its fields are obsolete.
    2. DHCP message format.
      Operation
      Hdwr Type
      Hdwr len
      Hops
      Transaction ID
      Seconds Elapsed
      Flags
      Client IP Address
      Your IP Address
      Server IP Address
      Gateway IP Address
      Client Hdwr Address (16 bytes)
      Server host name (64 bytes)
      Boot file name (128 bytes)
      Options (variable)
      1. The Operation is simply a 1 or 2 for client-to-server or server-to-client. The real operation is defined in the options section.
      2. Hardware type and length: Usually Ethernet, with length 6.
      3. Hops is part of relaying, see later.
      4. Transaction Identifier is a random number used to associate requests with responses, so when you get an answer, you know what question it is to.
      5. The server and boot file names are for remote booting. If provided, the client boots the indicated file from the indicated server. Not used much anymore.
      6. Client IP: Client's current IP address, if known, or zero.
      7. Your IP: Address being provided by a server to a client. Set to zero in other contexts.
      8. Server IP: The IP of the DHCP server, so client can send future message directly.
      9. Gateway IP: The address of a DHCP relay, discussed later.
      10. Options: Where the action is
        1. This is a string of key/value pairs. (The option keys are given by code number, not string names. Values often are strings.)
        2. As the protocol evolved, rather than adding more fields to the message, they just added more option keys.
        3. The most important is DHCP Message Type (option 53), which is what tells what the message is really for, not the the Operation from the main fields.
        4. Other options request or receive client host name, DNS server address, router information, and pretty much anything else you want a connecting host to know.
    3. Operation
      1. Booting machine broadcasts a DHCPDISCOVER request to 255.255.255.255:67.
      2. Server responds with a DHCPOFFER to 255.255.255.255:68. Contains a “Your IP” address, and other parameters in the options section.
        Note: Even though this is sent to a broadcast IP address, since the client doesn't yet know its IP address, the hardware packet is usually directed to the requestors MAC address so as not to create more broadcast LAN traffic.
      3. Client accepts by sending a DHCPREQUEST echoing the assignment.
      4. Server responds with DHCPACK (okay) or DHCPNAK (no).
        There wouldn't normally be much reason to say no, but in a busy network, with a lot going on, something might have changed since the offer. The client would start again with a DHCPDISCOVER.
      5. A client wishing to reuse a previous address starts with the DHCPREQUEST, which the server may allow or not.
      6. On shutdown, the host sends DHCPRELEASE to surrender its address.
      7. Addresses are not given permanently; they are said to be “leased.” When a client gets an address, the assignment expires after some period specified by the server.
      8. Clients typically ask for an extension when the period is about up using a new DHCPREQUEST.
      9. Leasing is used so the address can be reclaimed eventually, even if the client is unable to DHCPRELEASE.
    4. Address allocation.
      1. In a business or school where only certain machines are allowed, the DHCP server may assign a specific IP based on its MAC address.
        1. Here, for instance, you get the same IP whenever you connect the same machine.
        2. If your machine isn't known, you don't get an address.
      2. A public net, such as a coffee shop or a hotel, will assign IP addresses randomly out of a specified range.
      3. Apple is trying to break DHCP.
        1. Apple has started using random numbers instead of true MAC addresses for all networking functions. This is done to frustrate tracking.
        2. But it breaks DHCP that assigns IPs by MAC, and can exhaust random-assignment pools by getting a new IP on every connection.
        3. For latter, just set a short lease time.
        4. For the former, I'm reading that some of these will try the true address if they can't get an address from the random one. (Don't know if that info is new, old, or just wrong.)
  3. DHCP Relay
    1. Generally, packets bound to the limited broadcast address, 255.255.255.255 used for discovery, are not forwarded by an IP router; they are limited to one physical network.
    2. Instead of putting a DHCP server on every segment, an organization may put it on one, and set up DHCP relays on the the others.
    3. These will accept and forward the DHCPDISCOVER to the true server.
    4. The relay puts its own IP in the router address field to help the DHCP server know what address to offer.
    5. Conversation can generally continue from there without broadcast, perhaps with the relay forwarding when needed.
    6. The Hops field in the DHCP message tells how many times it's been relayed, and can be dropped if the DHCP server thinks it is too large. Purpose much like the IP TTL.
  4. IP6 does not need DHCP for a host to find its address; neighbor discovery and the fact the host can compute its own host number takes care of that. It will use DHCP to find other parameters.