Ethernet – How does DHCP assign an IP address

DHCP packets - aren't they always supposed to be broadcasted?

No, DHCP offers can be sent as unicast or broadcast. The layer-3 address doesn't really matter if it is unicast or broadcast because the frame is being delivered on the LAN by the layer-2 address.

From RFC 2321, Dynamic Host Configuration Protocol (emphasis mine):

In the case of a client using DHCP for initial configuration (before the client's TCP/IP software has been completely configured), DHCP requires creative use of the client's TCP/IP software and liberal interpretation of RFC 1122. The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured; DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured.

To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured as discussed in the previous paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents. Figure 2 gives the format of the 'flags' field.

                              1 1 1 1 1 1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |B|             MBZ             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          B:  BROADCAST flag
          MBZ:  MUST BE ZERO (reserved for future use)
          Figure 2:  Format of the 'flags' field

According to the DHCP RFC (2131) it is the responsibility of both the server and client to detect duplicate addresses. The server should check using ICMP or similar and the client should check using ARP or similar:

In some environments it will be necessary to reassign network addresses due to exhaustion of available addresses. In such environments, the allocation mechanism will reuse addresses whose lease has expired. The server should use whatever information is available in the configuration information repository to choose an address to reuse. For example, the server may choose the least recently assigned address. As a consistency check, the allocating server SHOULD probe the reused address before allocating the address, e.g., with an ICMP echo request, and the client SHOULD probe the newly received address, e.g., with ARP.

In the case where the client detects it has received a duplicate address, it must reject the address with DHCPDECLINE and then attempt to obtain another address after a backoff period.

The client receives the DHCPACK message with configuration parameters. The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address), and notes the duration of the lease specified in the DHCPACK message. At this point, the client is configured. If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server and restarts the configuration process. The client SHOULD wait a minimum of ten seconds before restarting the configuration process to avoid excessive network traffic in case of looping.

Note: all of these statements use the SHOULD key word, so although they are recommended, they are not mandatory (apart from the address rejection which is mandatory)

RFC 5227 provides more details on how clients can carry out IPv4 Address Conflict Detection