7.8 IPv6 Socket Options
These socket options are processed by IPv6 and
have a level of
IPPROTO_IPV6. We defer discussion of the multicasting
socket options until Section 21.6. We
note that many of these options make use of ancillary data with the recvmsg
function, and we will describe this in Section 14.6. All
the IPv6 socket options are defined in RFC 3493 [Gilligan et al.
2003] and RFC 3542 [Stevens et al. 2003].
IPV6_CHECKSUM Socket
Option
This socket option specifies the byte offset
into the user data where the checksum field is located. If this
value is non-negative, the kernel will: (i) compute and store a
checksum for all outgoing packets, and (ii) verify the received
checksum on input, discarding packets with an invalid checksum.
This option affects all IPv6 raw sockets, except ICMPv6 raw
sockets. (The kernel always calculates and stores the checksum for
ICMPv6 raw sockets.) If a value of -1 is specified (the default),
the kernel will not calculate and store the checksum for outgoing
packets on this raw socket and will not verify the checksum for
received packets.
All protocols that use IPv6 should have a
checksum in their own protocol header. These checksums include a
pseudoheader (RFC 2460 [Deering and Hinden 1998]) that includes the
source IPv6 address as part of the checksum (which differs from all
the other protocols that are normally implemented using a raw
socket with IPv4). Rather than forcing the application using the
raw socket to perform source address selection, the kernel will do
this and then calculate and store the checksum incorporating the
standard IPv6 pseudoheader.
IPV6_DONTFRAG Socket
Option
Setting this option disables the automatic
insertion of a fragment header for UDP and raw sockets. When this
option is set, output packets larger than the MTU of the outgoing
interface will be dropped. No error needs to be returned from the
system call that sends the packet, since the packet might exceed
the path MTU en-route. Instead, the application should enable the
IPV6_RECVPATHMTU option (Section 22.9) to
learn about path MTU changes.
IPV6_NEXTHOP Socket
Option
This option specifies the next-hop address for a
datagram as a socket address structure, and is a privileged
operation. We will say more about this feature in Section
22.8.
IPV6_PATHMTU Socket
Option
This option cannot be set, only retrieved. When
this option is retrieved, the current MTU as determined by path-MTU
discovery is returned (see Section 22.9).
IPV6_RECVDSTOPTS Socket
Option
Setting this option specifies that any received
IPv6 destination options are to be returned as ancillary data by
recvmsg. This option defaults to OFF. We will describe the
functions that are used to build and process these options in
Section 27.5.
IPV6_RECVHOPLIMIT Socket
Option
Setting this option specifies that the received
hop limit field is to be returned as ancillary data by
recvmsg. This option defaults to OFF. We will describe
this option in Section 22.8.
There is no way with IPv4 to obtain the received
TTL field.
IPV6_RECVHOPOPTS Socket
Option
Setting this option specifies that any received
IPv6 hop-by-hop options are to be returned as ancillary data by
recvmsg. This option defaults to OFF. We will describe the
functions that are used to build and process these options in
Section 27.5.
IPV6_RECVPATHMTU Socket
Option
Setting this option specifies that the path MTU
of a path is to be returned as ancillary data by recvmsg
(without any accompanying data) when it changes. We will describe
this option in Section 22.9.
IPV6_RECVPKTINFO Socket
Option
Setting this option specifies that the following
two pieces of information about a received IPv6 datagram are to be
returned as ancillary data by recvmsg: the destination
IPv6 address and the arriving interface index. We will describe
this option in Section 22.8.
IPV6_RECVRTHDR Socket
Option
Setting this option specifies that a received
IPv6 routing header is to be returned as ancillary data by
recvmsg. This option defaults to OFF. We will describe the
functions that are used to build and process an IPv6 routing header
in Section 27.6.
IPV6_RECVTCLASS Socket
Option
Setting this option specifies that the received
traffic class (containing the DSCP and ECN fields) is to be
returned as ancillary data by recvmsg. This option
defaults to OFF. We will describe this option in Section
22.8.
IPV6_UNICAST_HOPS Socket
Option
This IPv6 option is similar to the IPv4
IP_TTL socket option. Setting the socket option specifies
the default hop limit for outgoing datagrams sent on the socket,
while fetching the socket option returns the value for the hop
limit that the kernel will use for the socket. The actual hop limit
field from a received IPv6 datagram is obtained by using the
IPV6_RECVHOPLIMIT socket option. We will set this socket
option with our traceroute program in Figure 28.19.
IPV6_USE_MIN_MTU Socket
Option
Setting this option to 1 specifies that path MTU
discovery is not to be performed and that packets are sent using
the minimum IPv6 MTU to avoid fragmentation. Setting it to 0 causes
path MTU discovery to occur for all destinations. Setting it to鈥?
specifies that path MTU discovery is performed for unicast
destinations but the minimum MTU is used when sending to multicast
destinations. This option defaults to 鈥?. We will describe this
option in Section 22.9.
IPV6_V6ONLY Socket
Option
Setting this option on an AF_INET6
socket restricts it to IPv6 communication only. This option
defaults to OFF, although some systems have an option to turn it ON
by default. We will describe IPv4 and IPv6 communication using
AF_INET6 sockets in Sections 12.2 and
12.3.
IPV6_XXX Socket Options
Most of the IPv6 options for header modification
assume a UDP socket with information being passed between the
kernel and the application using ancillary data with
recvmsg and sendmsg. A TCP socket fetches and
stores these values using getsockopt and
setsockopt instead. The socket option is the same as the
type of the ancillary data, and the buffer contains the same
information as would be present in the ancillary data. We will
describe this in Section 27.7.
|
