Peter Memishian wrote: >.... >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. > >
Hmmm.... DHCP works on non-local LANs because of special forwarding performed for DHCP/BOOTP by routers. The implication of this option is that if the ttl is set for a broadcast packet, it will somehow make it past other routers/things on the network. That does not happen. I'd recommend updating the spec to remove the reference to "inducing broadcast storms" - this has nothing to do with why it should be consolidation private, if in fact it should be private. Given that we have IP_TTL as an option for getsockopt, why shouldn't we also implement that for setsockopt? And/or why would that be inappropriate for this problem? How would IP_BROADCAST_TTL interact with IP_TTL? To look into the future, can you explain why we would need to support setting IP_TTL, IP_BROADCAST_TTL and IP_MULTICAST_TTL, all on the same socket? Darren
