HP-UX TCP/IP Performance White Paper, March 2008

60
IPv6 Tunables
ip6_def_hop_limit:
Sets the default value of the Hop Limit field in the IPv6 header.
[1,255] Default: 64
The Hop-Limit field of the IPv6 header is used to ensure that an IPv6 datagram eventually "dies" on the
network. Each time an IPv6 datagram goes through an IPv6 router, the Hop-Limit is decremented by one
hop. When an IPv6 datagram's Hop-Limit reaches zero, it is discarded. This can be rather useful in the face
of routing loops - without the decrementing Hop-Limit datagrams would run through the loop forever.
Note that this is the value used for generic IPv6 purposes, for example when generating a response to
ICMPv6 “echo request.” The Hop-Limit of IPv6 datagrams containing either UDP datagrams or TCP
segments is controlled via udp_def_hop_limit or tcp_ip6_hop_limit respectively. The Hop-Limit
used for raw IPv6 access is set via rawip6_def_hop_limit.
ip6_forwarding:
Controls how IPv6 hosts forward packets: Set to 0 to inhibit
forwarding; set to 1 to always forward when the number of interfaces
on the system is 2 or more. [0,1] Default: 1
The ip6_forwarding tunable can be thought-of as the "master forwarding switch." If it is set to zero, no
IPv6 datagrams will be forwarded outside the box. If it is set to one, IPv6 datagrams may be forwarded
outside the box. The IPv6 forwarding can be controlled per-interface as well (see ifconfig(1M) man
page for “forward” option).
ip6_fragment_timeout:
Set the amount of time IPv6 fragments are held while waiting for
missing fragments.
The IPv6 specification (RFC 2460) specifies 60 seconds as the time-out
period for reassembly of IPv6 datagrams. This is a long time, but may
be appropriate for reassembling datagrams that have traversed an internet.
On local file server systems, on the other hand, fragmentation reassembly
will either take place very quickly, or not all, i.e., if all fragments
are not received at about the same time, it is likely that one was dropped
by the local interface, and will never arrive. In this case, holding
fragments for 60 seconds may only exacerbate the problem.
For every IPv6 packet that is to be fragmented, the source node generates
an Identification value for each fragment. The Identification must be
different than that of any other fragmented packet sent recently with
the same Source Address and Destination Address. If insufficient fragments
are received to complete reassembly of a packet within 60 seconds of the
reception of the first-arriving fragment of that packet, reassembly of
that packet must be abandoned and all the fragments that have been
received for that packet must be discarded.
If the parameter is set to a value that is large enough that IPv6
wraps the identification value in its fragments (IPv6 starts to re-use
its identification value while holding fragments for reassembly), it is