I'm mid-way through the list of ndd tunables (see updates to http://cr.opensolaris.org/~sowmini/ndd.html which also briefly describes these parameters) and came across some items that don't look like they belong in ndd at all- these look like good candidates for setsockopts, or things that ought to be auto-tuned by the stack.
I'd like to find out if anyone's using these, or can think of reasons why these should belong in ndd: - setting ip/tcp/udp/icmp TTL through ndd: Do we really want to change the default ttl for all ip/tcp/udp/icmp packets? Esp when there are socket options like IP_TTL, IPV6_UNICAST_HOPS, IP_MULTICAST_TTL for this? (See also 5046705) We have ip_def_ttl, ip6_def_hops, tcp_ipv4_ttl, tcp_ipv6_hoplimit, icmp_ipv4_ttl, icmp_ipv6_hoplimit, udp_ipv4_ttl, udp_ipv6_hoplimit, ip_broadcast_ttl. Aren't IP_TTL, IPV6_UNICAST_HOPS, IP_MULTICAST_TTL sufficient? - icmp_bsd_compat: sounds like something that should be a setsockopt, if we want something other than the default. Does anyone actually alter the default here? - [ip, tcp, icmp, udp]_wroff_extra- who modifies these from defaults? The stack should self-tune these based on the ill_phys_addr_length it learns through DLPI. - ip_icmp_return_data_bytes, ip6_icmp_return_data_bytes- for IPv4, rfc 1812 (Section 4.3.2.3) says that the icmp datagram should contain as much info from the offending packet as will fit in 576 bytes. Shouldn't this be auto-tuned by the stack? any thoughts or insights into the reason these are ndd tunables would be appreciated! Note that the above list is *not* exhaustive- there may be more ndd "tunables" that would be better dealt with through other means. --Sowmini
