Overview
--------

   This case proposes a consolidation-private IP_BROADCAST_TTL socket option
   which will be used by the DHCP client to preserve interoperability with
   broken DHCP servers.  Patch binding is requested.  Since this case should
   be straightforward and since we'd like to address the interoperability
   issue before the current build closes, the timer is set for Friday,
   November 9th.

Details
-------

   To prevent broadcast packet storms, the TCP/IP stack sends all broadcast
   packets with a time-to-live of 1 (though this can be overridden with the
   ndd ip_broadcast_ttl tunable).  This restriction has existed since
   Solaris 2.0 (if not earlier) and has not generally been an issue.

   However, some broken DHCP servers and DHCP relay agents -- especially
   those that also act as routers -- decrement the TTL of incoming packets
   before checking whether the packet is for them.  As a result, broadcast
   DHCP traffic will be dropped by the DHCP server or DHCP relay, and as a
   result the DHCP client will be unable to obtain a lease.

   Until recently, the DHCP client has used DLPI to send broadcast DHCP
   traffic, merilly averting this issue (indeed, the old DHCP client DLPI
   explicitly set the TTL to 255 when constructing IP packets to combat this
   problem).  However, now that the DHCP client is sockets-based, the issue
   has arisen.

   To address this problem, an IP_BROADCAST_TTL socket option is proposed.
   This option will be identical to the existing stable IP_MULTICAST_TTL
   socket option, but will apply to broadcast traffic.  Since sending
   broadcast with arbitrary TTLs has no other known use-cases and may
   induce broadcast storms, IP_BROADCAST_TTL will be consolidation private
   and require the PRIV_NET_RAWACCESS privilege.  Once the option is
   enabled, its value will override the ip_broadcast_ttl ndd tunable when
   sending broadcast packets on the given socket.

-- 
meem

Reply via email to