The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Network Configuration and Management Protocols (BOOTP, DHCP, SNMP and RMON)            9  Host Configuration and TCP/IP Host Configuration Protocols (BOOTP and DHCP)                 9  TCP/IP Bootstrap Protocol (BOOTP)

BOOTP Client/Server Messaging and Addressing 1 2 BOOTP Message Format

Interpretation of the Client IP Address (CIAddr) Field

A complication can arise when a client chooses to specify an IP address in the CIAddr field in its request. The problem is how exactly to interpret this field. Does it mean that the client is already using this IP address? Or is it just the one it used last time it was booted? Then there is the related problem of what to do if the server supplies an address in the YIAddr that is different from the one the client is using. Should the server's provided address override the client's address? Or should the client ignore it? Who makes the decision, the server or the client?

Much confusion occurred due to the vagueness of the original standard in this regard, and this led to non-uniformity in how different implementations chose to handle this issue. There were even some implementations that used the CIAddr to mean “the client requests this IP address”, which was never part of BOOTP functionality. This is an especially bad idea since it could lead directly to BOOTP replies never reaching the client.

RFC 1542 was written in part to try to clean up this mess. It suggests that the following is the best way to handle the meaning of these fields:

• If a client is willing to accept whatever IP address the server provides, it sets CIAddr to all zeroes, even if it knows a previous address.
  
  
• If the client fills in a value for the field, it is saying it will use this address, and must be prepared to receive unicast messages sent to that address.
  
  
• If the client specifies an address in CIAddr and receives a different address in the YIAddr field, the server-provided address is ignored.

Note that not all hardware devices may necessarily agree with this interpretation as provided by RFC 1542, so there are still potential interoperability issues here with older equipment. RFC 1542 was written in 1993, so this is probably not much of an issue any more.

BOOTP Client/Server Messaging and Addressing 1 2 BOOTP Message Format