PSARC/2007/639 IP_BROADCAST_TTL socket option

[James Carlson]

Darren Reed writes:
> <digression>
> Hanging onself in this manner generally requires cooperation
> from routers but since smurf (and other) attacks become wide
> spread, forwarding of packets to networks where the destination
> address becomes interpreted as a broadcast is generally disabled
> by default - eg:
> # ndd /dev/ip ip_forward_directed_broadcasts
> 0
> </digression>

True.  Fortunately, DHCP doesn't normally use simply forwarded
broadcasts but instead relies on proxy behavior.

The problem that's being worked around here is broken behavior in a
few other implementations.

> Or in other words, why shouldn't we just fix IP_TTL to apply
> to both unicast and broadcast packets (but not multicast)
> like everyone else?

That'd alter existing applications.  They don't expect IP_TTL to
change the way broadcast works, and it'd be a "surprise" (read: "bug")
if it suddenly started doing so.  There's no way to guarantee that
applications _won't_ trip on this except to keep it out of the way.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677