TCP/IP Notes

Intro / Network Addressing / Network Addressing IPv6 / Packet Headers / Networking and Data Link Layers / Transport Layer Protocols / Application Layer Protocols / IP Routing / ICMP / DHCP / Name Resolution and DNS / Security

DHCP

Dynamic Host Configuration Protocol is a TCP/IP Application Layer protocol designed to provide IP autoconfiguration. Originally this job required administrators to configure each IP host device or network interface manually, while keeping track of which machines were assigned to which addresses; DHCP allows individual clients to find the information they need themselves by querying other network devices, namely a DHCP server or other device acting within this capacity. The Bootstrap Protocol (BOOTP) was an early attempt to accomplish this task. It was developed in the 1970s as a way of providing network access to diskless workstations for obtaining startup information, and because DHCP originates from this protocol backwards compatibility is possible (https://tools.ietf.org/html/rfc1534), however BOOTP usage is diminishing.

The number of nodes connecting to the Internet (including mobile smartphone and other portable devices) combined with the need to re-address clients (coffee shop example) makes DHCP for administrative work much easier.

In addition to DHCP, Microsoft has also developed an autoconfiguration mechanism but without relying upon a client-server approach ("stateless autoconfiguration") called Automatic Private IP Addressing (APIPA).

In IPv6, DHCP has been upgraded (DHCPv6). It provides both stateful and stateless configuration forms as in IPv4, but in IPv6 hosts can use either/or, or a combination of both methods. In IPv6 address autoconfiguration, clients use Router Advertisement to become informed on which method to use.

DHCP in basic terms is a service which allows a host to grab available IP addresses from a listening server. Addresses can also be manually reserved for specific hosts (static address allocation). For administrative work this is ideal for gateways, wireless access points and servers. DHCP provides clients with the addresses to gateway devices and DNS servers, and can can manage these configurations over time.

DHCP servers can manage one or more ranges of IP addresses, each of which being referred to as an 'address pool' (meaning available addresses within a range) or an 'address scope' (any range of IP addresses that are controlled by a particular server). Within each scope, individual addresses or address ranges can be excluded from dynamic allocation among clients, which forms the difference between dynamic 'leases' and static allocations.

From a client perspective:

1) When a IP address is automatically obtained (default for Windows Vista, 7, and Server 2008), the DHCP service runs (Windows).

2) When a client accesses the network it broadcasts a DHCP address request.

3) A DHCP server within the network receives the request and responds with a message indicating that it can grant an address lease. If no server is present, a DHCP relay agent forwards the address request to a known server address.

4) The client accepts the address lease offer and responds with another message.

5) The server gives the client an IP address for a set time period.

6) When the time period expires, the client attempts to renew the lease.

Software elements
-------------------------

To define a DHCP networking environment, three pieces of software work in tandem:

DHCP Client - The client software is generally included in all major operating systems.

DHCP Server - The software which listens and responds to clients and manages address pools.

DHCP Relay Agent - Intercepts broadcast address requests on a local network segment and repackages these requests as unicast to one or more DHCP server.

A DHCP request is a message from client to server, and a DHCP reply in response to the client request is sent from the server to a relay agent which uses the client MAC address to forward it. Subsequent requests happen as unicast directly from the DHCP server which has now obtained an IP address and default IP gateway address.

Leases
---------

Typically, leases ranging from one to three weeks are found in workstation environments in which the machines are stationary. In situations where many temporary machines come and go, the lease time may be between one to three days, or even four to eight hours. Lease information can be obtained by analyzing DHCP packets.

A DHCP server recognizes two types of address leases:

Manual - The administrator assigns the IP addresses by associating individual clients with individual IP addresses. Generally a static pool of IP addresses will be delegated for this purpose (to statically allocate known gateways, WAPs, server, etc.).

Dynamic - Addresses assigned to clients for specific lengths of time.

A standard networking scheme might have static IP addresses for servers serving various purposes: DNS, e-mail, file and print, database, etc. Routers, gateways, and other devices which act as networking bridges may also have dedicated static addresses, whereas clients will generally be assigned dynamic addresses. In this configuration servers do not need to maintain a list of client names and IP addresses.

On Windows, the ipconfig command supports /release and /renew switches to release and renew current leases.

On Unix-like systems this can be done via the dhclient command.

$ sudo dhclient -r
$ sudo dhclient

or

# ifdown eth0
# ifup eth0
# /etc/init.d/network restart

or

# /etc/init.d/networking restart

IPv4 Autoconfiguration
-------------------------------

The two types of address autoconfiguration mechanisms include DHCP and APIPA (Automatic Private IP Addressing), with the latter generally used as a fallback device if a DHCP server does not respond to a client request.

APIPA - Initially implemented by Microsoft starting in Windows 98, standardized in RFC 3927 (https://tools.ietf.org/html/rfc3927). The address block 169.254.0.0/16 is reserved for APIPA, with 169.254.1.0 - 169.254.254.255 used for host addresses and the first/last 256 addresses reserved, meaning the 169.254/16 addresses should not be configured for use in DHCP or DNS or routed to an external network.

If a DHCP server does not respond to a client request, the client will still send response messages every 5 minutes, and if the server eventually does reply with an address the client will favor this over the APIPA address (an interface is only allowed to have one IPv4 address while in autoconfiguration mode). Also, APIPA will only work if the client does not have a manual IP address assigned (DHCP is present).

APIPA address assignment uses a pseudo-random number generator to derive a unique address, and while APIPA allows hosts to communicate on a local link basis, it will not allow routed communication to hosts on other networks (therefore it will not be useful for servers not locally available).

DHCPv4 - When a client initially broadcasts a request message, it is known as 'DHCP Discovery.' DHCP servers which can discern the discovery broadcast provide the client with a IP address and a lease time. The servers receive this message on port number 67, and messages from server to client are read on port number 68. DHCP broadcasts are limited to the local link level, which make use of relay agents to help route the DHCP Discovery broadcasts to other network segments within the local link. Multiple DHCP servers can be placed into a network to provide fault tolerance, but the address pool must be divided between the servers to guarantee address uniqueness.

DHCP servers typically PING an address before offering it to a client, and the clients broadcast ARP packets to determine if the provided address is already in use. If this is the case the client transmits a DHCP decline message to the server, which then blocks that address from being assigned again and offers the client a new address.

In Windows Server 2008 a feature called 'Windows clustering' allows two or more servers to be managed as a single system, which can help with failures related to any one server and shift responsibility from one server to another.

DHCP Discovery uses four packets in a sequence (aka "boot sequence") which can be remembered as "DORA"

1) DHCP Discover packet - Client broadcasts a Discover packet which identifies the client hardware address. The Discover packet's IP header contains the source IP address 0.0.0.0 and the broadcast destination address 255.255.255.255. If a client was previously on a network, it might also define a preferred address (typically the last address the client used; applies primarily to Windows 2000 and later). During this stage a series of requests known as DHCP Options can be specified as defined in RFC 2132 (https://tools.ietf.org/html/rfc2132).

2) DHCP Offer packet - Server sends Offer packet. If the server can ARP the client MAC address it sends the packet by unicast, otherwise the entire Discovery sequence will use broadcast. The Offer packet includes the IP address that is offered to the client and sometimes answers to the requested options specified in the previous step.

3) DHCP Request packet - Client either accepts the offer by issuing a Request packet or rejects the offer by sending a Decline packet (usually a client sends a decline only if it receives more than one offer, e.g. accepting the first offer and discarding subsequent offers in networks with more than one DHCP server).

4) DHCP Acknowledgement packet - Server sends client Acknowledgement packet to indicate completion of Discovery process, also containing answers to configuration options specified by the previous Request packet.

After this sequence, a client will perform a duplicate IP address test following acknowledgement packet receipt.

DHCP DORA

Address Renewal
-----------------------

The DHCP client takes the time at which a lease was renewed (renewal time) and the rebinding time to start a renewal process at the half-way point of the lease period. If the client cannot renew the address, it must go through another DHCP server, assuming the original is no longer available. If this fails, the host must release the address.

Renewal Time (T1) - Defined as the time when the client tries to renew an address by contacting the DHCP server which originally granted the address and lease. The Renewal packet is sent as unicast directly to the server.

0.5 * duration_of_lease

Rebinding Time (T2) - Defined as the time that the client begins to broadcast a renewal request for an extended lease time from another server.

0.875 * duration_of_lease

If the client does not receive a reply to the renewal request, it divides the remaining time between the current time and the T2 time and then retries. If the client does not receive a reply to the rebinding request, it reduces the remaining time between the current rebinding time and the expiration of the lease time and retries. The retry rebinding process continues until 60 seconds before the lease expiration time. If the client is eventually unsuccessful, it releases the address and reinitializes (starts DHCP Discovery process over again, using source IP address 0.0.0.0).

Address Release
----------------------

A client can release its address by sending a DHCP Release packet to the server. The packet is sent over UDP, but the server does not send any acknowledgement. The Discovery process starts over.

DHCP Packet Structures
--------------------------------

Operation Code (OPCODE)/Message Type Field - 1 byte, indicates whether the packet is a DHCP Request (0x01) or a DHCP Reply (0x02). Details for the type of request/reply are defined in the Options.

Hardware Type Field - 1 byte, identifies hardware address type and matches the values for assigned ARP hardware type definitions (see: https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-parameters-2).

Hardware Length Field - 1 byte, indicates length of hardware address.

Hops Field - Set to 0 by the client, may be used by relay agents.

Transaction ID Number Field - 4 bytes, contains a random number selected by the client used to match requests and responses between the client and server.

Seconds Since Boot or Seconds Elapsed Field - 2 bytes, indictaes the number of seconds which have elapsed since the client began requesting a new address, or since the renewal of an existing address.

Flags Field - 2 bytes. The first bit set to 1 indicates the client cannot accept unicast MAC-layer datagrams before the IP software is configured. The remaining bits are set to 0.

Client IP Address Field - 4 bytes.

Your IP Address Field - 4 bytes, contains the address being offered by the server.

Server IP Address Field - 4 bytes, contains the address of the server.

Gateway or Relay Agent IP Address Field - 4 bytes, contains the address of the relay agent if existing.

Client Hardware Address Field - 16 bytes, contains the client MAC address.

Server Host Name Field - 64 bytes, can contain the server hostname (optional).

Boot File Field - Boot filename (optional).

DHCP Option Field - Optional parameters (see: https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml).

One option which is required in all DHCP packets is Option 53: DHCP Message Type, which indicates the purpose of the message:

(0x01) DHCP Discover - Sent by client to locate available servers.

(0x02) DHCP Offer - Sent by server in response to Discover.

(0x03) DHCP Request - Sent by client to server requesting offered parameters.

(0x04) DHCP Decline - Sent by client to server indicating invalid parameters.

(0x05) HCP ACK - Sent by server to client with configuration parameters.

(0x06) DHCP NAK - Sent by client to server to refuse a request for configuration parameters.

(0x07) DHCP Release - Sent by client to server to release address and cancel lease.

(0x08) DHCP Inform - Send by client to server to ask for only configuration parameters.

Communications with DHCP Relay Agent
------------------------------------------------------

DHCP communications use a mix of broadcast and unicast. For example clients must rely on broadcast service requests until they obtain addresses following DORA. Once this happens they can then use unicast. DHCP servers examine client packets to determine whether to use broadcast or unicast for response depending on the situation. The boot process uses broadcast transmissions heavily, but since most routers do not forward broadcasts relay agents can be used (this would be required if there is not a DHCP server on each network segment). Relay agent functionality can be loaded onto a router connected to the segment containing DHCP clients, and is configured with the DHCP server address which can then communicate unicast directly with the server.

IPv6 Autoconfiguration
------------------------------

Two basic approaches to IPv6 autoconfiguration are stateless and stateful. Stateless provides required router configuration information to all potential clients, whereas stateful implies that the server must maintain awareness of the address pool, particularly status.

Stateless Address Autoconfiguration - On network segments which support multicasting, RFC 4862 (https://tools.ietf.org/html/rfc4862) defines several tools allowing for stateless autoconfiguration. The ND protocol (Neighbor Discovery) allows routers to be configured to provide the minimum amount of information necessary for clients to join the network link (e.g., prefix of network segment, router address, segment MTU and preferred number of maximum hops).

When a client initializes on a IPv6 network link, the network interface calculates its own 64-bit ID and forms a link local address by appending the ID to the well known link local network prefix of FE80::, creating a "global" unicast address via Router Solicitation and Router Advertisement messages.

The node IDs for IPv6 addressing can be constructed from different sources, including Modified EUI-64, random number generator, and Cryptographically Generated Addresses (CGA).

Stateful Address Autoconfiguration - Instead of the previous example where routers supply the network prefix, they can instead supply flags for clients to obtain IPv6 addresses via DHCPv6, which is similar to DHCPv4 under IPv4 in that both rely on servers to hold database information about hosts, IP addresses and other configuration parameters.

Nodes under IPv6 can gain a local address without any help from DHCPv6 (clients can actively search for a server using multicast solicitations, discovering whether the server is on the local link). Clients in IPv6 environments can also use a relay server on a local network segment to receive configuration information from an off-link server. Also unlike DHCPv4, the DHCPv6 server does not supply the client with the default gateway address (the client instead receives this from Router Advertisement).

In this situation, the router is equipped with it's RA A flag set to 'off' and the M and O flags set to 'on,' which tells the client to obtain the IPv6 address from a DHCPv6 server. The client sends a DHCPv6 solicitation message to locate the server and to obtain its address and other other information, such as the DNS server address.

DHCPv6 stateful address autoconfiguration can also share certain aspects of a stateless configuration. In either case, clients depend on RA messages containing new or updated timer information for leases, and flags which direct the host to configure and use a new address. Using DHCPv6 can also dynamically update DNS records.

When both methods are combined it can be called 'DHCPv6 stateless.' In this situation routers on a local link are configured to provide pointers to DHCPv6 servers which can provide the necessary network information (the router is configured with RA A and L flags set to 'on,' the M flag set to 'off,' and the O flag set to 'on.' The router provides the network prefix, and the server provides DNS server information.

Unlike IPv4, in IPv6 address autoconfiguration lease time can be configured in RA messages (including lifetime timer configuration).

Functional States of IPv6 Address Autoconfiguration
---------------------------------------------------------------------

Tentative addresses - Occur as a host initializes an interface on a network segment to configure its own link local address. To verify uniqueness, the host sends out an NS with this address as destination. If another node responds the initializing node stops autoconfiguration. If a duplicate is not found, the new address is considered valid (Duplicate Address Detection).

Valid addresses - Usable based on the Valid Lifetime field in the Prefix Information option of the RA or the Valid Lifetime field in the DHCPv6 IA Address option, and are 'preferred' or 'deprecated.' The valid lifetime must be equal to or greater than the preferred lifetime value (when the valid lifetime expires, the address becomes invalid). Preferred addresses are based on the Preferred Lifetime field in the Prefix Information option of the RA or the Preferred Lifetime field in the DHCPv6 IA Address option (when the preferred lifetime expires but the valid lifetime is still active, the address becomes deprecated). Deprecated addresses allow hosts to continue to function while a lease is renewed (when the valid lifetime expires, the address becomes invalid).

Invalid addresses - Can't be used as either source or destination address when valid lifetime expires.

DHCPv6
-----------

DHCPv6 is defined in RFC 3315 (https://tools.ietf.org/html/rfc3315). DHCPv6 servers are not required to be on the same network segment as hosts (DHCPv6 relay service-configured routers can forward client requests to the server). Clients listen for DHCPv6 messages on UDP port 546, and servers/relay agents use UDP port 547.

DHCPv6 uses two multicast addresses:

FF02::1:2 - Link-scope multicast address used by clients to communicate with servers/relay agents on the same network segment.

FF05::1:3 - Site-scope multicast address used by server/relay agents to communicate with servers on the same network segment.

In DHCPv6, IPv6 addresses are not bound to MAC addresses as they are in DHCPv4; Instead they are tied to the DHCP Unique Identifier (DUID), which must be globally unique for each client and server. DUIDs can be defined by one of three ways:

DUID-LLT - Link layer address plus time

DUID-EN - Vendor assigned unique ID based on Enterprise number

DUID-LL - Link layer address

Another difference is in Identity Association (IA), which is used by servers and clients to identify a group of IPv6 addresses. It is based off of an identity association identifier (IAID) and associated configuration information, with each host having a unique IAID for each interface. When the host sends a Solicit request to the server, it provides the IAID, and the server stores it in the lease table.

One of the main design goals behind IPv6 address autoconfiguration is the ability to perform the readdress processes with a minimal impact upon the network. This is accomplished mostly be changing the nature of timer values and network prefixes.

Message types and format fields for DHCPv6 can be found in RFC 3315 and: https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml.

DHCPv6 Stateful Message Exchange
------------------------------------------------

1) Host sends Router Solicitation.

2) Router replies with a Router Advertisement, with its A flag set to 'off' and the L, M, & O flags set to 'on.'

3) Host sends a Solicit message looking for DHCPv6 servers at link-scope multicast address FF02::1:2.

4) Server replies to host with an Advertise message, informing host it can provide IPv6 address and other configuration options.

5) Host sends a Request message, requesting IPv6 address and other configuration options (DNS address, domain name, etc.).

6) Server sends host a Reply message with the address/configuration options and timer information.

DHCPv6 Stateless Message Exchange
--------------------------------------------------

1) Host sends Router Solicitation message.

2) Router replies with a Router Advertisement message, with its A, L, & 0 flags set to 'on' and the M flag set to 'off.'

3) Host sends an Information-Request message, requesting only other configuration options (DNS address, domain name, etc.), looking for DHCPv6 servers at the link-scope multicast address FF02::1:2 and prepends network prefix to interface ID.

4) Server sends host a Reply message with other configuration options.

DHCPv6 Relay Message Exchange
---------------------------------------------

The DHCPv6 relay process is essentially the same as DHCPv6 stateful, but the location of the server is not on-link, necessitating that the on-link router is configured with relay capabilities.

1) Host sends Router Solicitation.

2) Router replies to host with Router Advertisement, with its A and L flags set to 'off' and the M and O flags set to 'on.'

3) Host sends Solicit message looking for DHCPv6 servers at link-scope multicast address FF02::1:2.

4) Router relay-forwards the host Solicit message to the server.

5) Server relay-replies to the router with an Advertise message, informing the host it can provide a IPv6 address and other configuration options.

6) Router replies with an Advertise message to the host.

7) Host sends a Request message, requesting IPv6 address and other configuration options (DNS address, domain name, etc.).

8) Router relay-forwards the host Request message to the server.

9) Server relay-replies to the router with a Reply message containing IPv6 address and other configuration options.

10) Router replies with a Reply message to the host.

In all cases of IPv6 address autoconfiguration, the DAD process must be executed to verify uniqueness.

RFCs defining stateless and stateful methods of IPv6 autoconfiguration processes include RFC 4862 (https://tools.ietf.org/html/rfc4862) and RFC 3315 (https://tools.ietf.org/html/rfc3315).

Further Reading
---------------------

Bootstrap Protocol
https://en.wikipedia.org/wiki/Bootp

Link-local Addresses IPv4
https://en.wikipedia.org/wiki/Apipa#IPv4

dhclient - Dynamic Host Configuration Protocol Client
https://linux.die.net/man/8/dhclient

DHCP Debugging and Handy TCPdump filters
https://blog.jasonantman.com/2010/04/dhcp-debugging-and-handy-tcpdump-filters/

Neighbor Discovery Protocol
https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol

IPv6 Interface Identifiers
https://msdn.microsoft.com/en-us/library/aa915616.aspx

Cryptographically Generated Address
https://en.wikipedia.org/wiki/Cryptographically_Generated_Address.