Peter Memishian wrote: > > DHCP works on non-local LANs because of special forwarding > > performed for DHCP/BOOTP by routers. > >I'm not sure why you call this "special forwarding" -- it's simply normal >DHCP relay agent behavior. Also, there is no requirement that a DHCP >relay agent be an IP router. > > > 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. > >I think it's relevant. If there's no use-case, we should not provide rope >to hang oneself. >
<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> > > Given that we have IP_TTL as an option for getsockopt, > > why shouldn't we also implement that for setsockopt? > >We do have it for setsockopt(). It affects unicast traffic. > Is there any dependency between IP_BROADCAST_TTL and SO_BROADCAST? > > How would IP_BROADCAST_TTL interact with IP_TTL? > >It doesn't interact since IP_TTL only affects unicast traffic. > > > 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? > >One affects unicast, one affects broadcast, and one affects multicast. >IP_MULTICAST_TTL is the only one that's a stable API. BTW, this same >split exists with IPv6: IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS (of >course there is no V6 broadcast); both are documented in ip6(7P). > FWIW, this behaviour, of IP_TTL vs IP_BROADCAST_TTL vs IP_MULTICAST_TTL is going to differ from other platforms, increasing the difficulty of porting applications to/from Solaris. Whereas IP_MULTICAST_TTL seems to be common across the board, as to IP_TTL, IP_BROADCAST_TTL is not and in its place, IP_TTL is used. What benefit do we (Solaris and OpenSolaris) gain by being architecturally different in this to both BSD and Linux? 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? Darren
