Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY
messages directly to a client using unicast delivery. The IP
destination address (in the IP header) is set to the BOOTP 'yiaddr'
address and the link-layer destination address is set to the BOOTP
'chaddr' address. Unfortunately, some client implementations are
unable to receive such unicast IP datagrams until they know their own
IP address (thus we have a "chicken and egg" issue). Often, however,
they can receive broadcast IP datagrams (those with a valid IP
broadcast address as the IP destination and the link-layer broadcast
address as the link-layer destination).
If a client falls into this category, it SHOULD set (to 1) the
newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
messages it generates. This will provide a hint to BOOTP servers and
relay agents that they should attempt to broadcast their BOOTREPLY
messages to the client.
If a client does not have this limitation (i.e., it is perfectly able
to receive unicast BOOTREPLY messages), it SHOULD NOT set the
BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
DISCUSSION:
This addition to the protocol is a workaround for old host implementations. Such implementations SHOULD be modified so
that they may receive unicast BOOTREPLY messages, thus making
use of this workaround unnecessary. In general, the use of
this mechanism is discouraged.
I'll check DHCP IB implementation from my previous SRU from:
As David stated,
Per RFC 1541:
https:/ /tools. ietf.org/ html/rfc1541
"DHCP uses the 'flags' field [21]. The leftmost bit is defined as the BROADCAST (B) flag"
Taking us to RFC 1542:
https:/ /tools. ietf.org/ html/rfc1542
3.1 Client use of the 'flags' field
3.1.1 The BROADCAST flag
Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY
messages directly to a client using unicast delivery. The IP
destination address (in the IP header) is set to the BOOTP 'yiaddr'
address and the link-layer destination address is set to the BOOTP
'chaddr' address. Unfortunately, some client implementations are
unable to receive such unicast IP datagrams until they know their own
IP address (thus we have a "chicken and egg" issue). Often, however,
they can receive broadcast IP datagrams (those with a valid IP
broadcast address as the IP destination and the link-layer broadcast
address as the link-layer destination).
If a client falls into this category, it SHOULD set (to 1) the
newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
messages it generates. This will provide a hint to BOOTP servers and
relay agents that they should attempt to broadcast their BOOTREPLY
messages to the client.
If a client does not have this limitation (i.e., it is perfectly able
to receive unicast BOOTREPLY messages), it SHOULD NOT set the
BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
DISCUSSION:
This addition to the protocol is a workaround for old host
implementatio ns. Such implementations SHOULD be modified so
that they may receive unicast BOOTREPLY messages, thus making
use of this workaround unnecessary. In general, the use of
this mechanism is discouraged.
I'll check DHCP IB implementation from my previous SRU from:
https:/ /bugs.launchpad .net/ubuntu/ +source/ isc-dhcp/ +bug/1401141
For this BROADCAST flag distinction on IB DHCP requests.