> 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. > 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. > 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). -- meem
