On 26/02/09 01:43 PM, [email protected] wrote:
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?
You're presuming that the application provides the user the ability
to configure this. Use of these knobs can assist when dealing with
applications that are either problematic or when the environment
is just a little bit different.
- 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_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?
The other relevant RFC here is 1122, see section 3.2.2.
We currently appear to default to 64, which is pretty good.
That's going to cover 99% of packets IP+TCP header data.
The real benefit in ensuring that all the IP+TCP/UDP/ICMP
header data is included. There's not a lot of benefit in sending
back 400 bytes of HTTP headers because the receiving stack
just won't use it.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
