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
