IP is the network layer protocol used by the Internet protocol family. Options
may be set at the IP level when using higher-level protocols that are based on
IP (such as TCP and UDP). It may also be accessed through a “raw
socket” when developing new protocols, or special-purpose applications.

There are several IP-level
setsockopt(2)/getsockopt(2)
options. IP_OPTIONS may be used to provide
IP options to be transmitted in the IP header of each outgoing packet or to
examine the header options on incoming packets. IP options may be used with
any socket type in the Internet family. The format of IP options to be sent is
that specified by the IP protocol specification (RFC 791), with one exception:
the list of addresses for Source Route options must include the first-hop
gateway at the beginning of the list of gateways. The first-hop gateway
address will be extracted from the option list and the size adjusted
accordingly before use. To disable previously specified options, use a
zero-length buffer:

setsockopt(s, IPPROTO_IP, IP_OPTIONS, NULL, 0);

IP_TOS and
IP_TTL may be used to set the
type-of-service and time-to-live fields in the IP header for
SOCK_STREAM,
SOCK_DGRAM and
SOCK_RAW sockets. For example,

If the IP_RECVDSTADDR option is enabled on a
SOCK_DGRAM socket, the
recvmsg(2) call will return the
destination IP address for a UDP datagram. The
msg_control field in the
msghdr structure points to a buffer that
contains a cmsghdr structure followed by the
IP address. The cmsghdr fields have the
following values:

If the IP_RECVDSTPORT option is enabled on a
SOCK_DGRAM socket, the
recvmsg(2) call will return the
destination port for a UDP datagram. The
msg_control field in the
msghdr structure points to a buffer that
contains a cmsghdr structure followed by the
port in 16-bit network byte order. The
cmsghdr fields have the following values:

If the IP_RECVTTL option is enabled on a
SOCK_DGRAM or
SOCK_RAW socket, the
recvmsg(2) call will return the
TTL of the received datagram. The msg_control
field in the msghdr structure points to a
buffer that contains a cmsghdr structure
followed by the TTL value. The cmsghdr fields
have the following values:

The IP_MINTTL option may be used on TCP and
UDP sockets to discard packets with a TTL lower than the option value. This
can be used to implement the Generalized TTL Security
Mechanism (GTSM) according to RFC 5082. To discard all packets with a TTL
lower than 255:

If the IP_IPSECFLOWINFO option is enabled on
a SOCK_DGRAM socket, the
recvmsg(2) call will return
information identifying the incoming IPsec SA for a UDP datagram. The
msg_control field in the
msghdr structure points to a buffer that
contains a cmsghdr structure followed by flow
information in 32-bit network byte order. When this information is passed to a
sendmsg(2) call the ID of the
incoming SA will be used for looking up the outgoing SA for the UDP datagram.
The cmsghdr fields for
recvmsg(2) and
sendmsg(2) have the following
values:

If the IP_RECVRTABLE option is enabled on a
SOCK_DGRAM socket, the
recvmsg(2) call will return the
source routing domain for a UDP datagram. The
msg_control field in the
msghdr structure points to a buffer that
contains a cmsghdr structure followed by the
routing table ID. The cmsghdr fields have the
following values:

When sending on a SOCK_DGRAM socket with
sendmsg(2), the source address
to be used can be passed as ancillary data with a type code of
IP_SENDSRCADDR. The
msg_control field in the
msghdr structure should point to a buffer
that contains a cmsghdr structure followed by
the requested source address. The cmsghdr
fields should have the following values:

Datagrams with a TTL of 1 are not forwarded beyond the local network. Multicast
datagrams with a TTL of 0 will not be transmitted on any network, but may be
delivered locally if the sending host belongs to the destination group and if
multicast loopback has not been disabled on the sending socket (see below).
Multicast datagrams with TTL greater than 1 may be forwarded to other networks
if a multicast router is attached to the local network.

For hosts with multiple interfaces, each multicast transmission is sent from the
primary network interface. The
IP_MULTICAST_IF option overrides the
default for subsequent transmissions from a given socket:

where addr is the local IP address of the
desired interface or INADDR_ANY to specify
the default interface. An interface's local IP address and multicast
capability can be obtained via the
SIOCGIFCONF and
SIOCGIFFLAGSioctl(2)'s. Normal applications
should not need to use this option.

If a multicast datagram is sent to a group to which the sending host itself
belongs (on the outgoing interface), a copy of the datagram is, by default,
looped back by the IP layer for local delivery. The
IP_MULTICAST_LOOP option gives the sender
explicit control over whether or not subsequent datagrams are looped back:

This option improves performance for applications that may have no more than one
instance on a single host (such as a router daemon), by eliminating the
overhead of receiving their own transmissions. It should generally not be used
by applications for which there may be more than one instance on a single host
(such as a conferencing program) or for which the sender does not belong to
the destination group (such as a time querying program).

A multicast datagram sent with an initial TTL greater than 1 may be delivered to
the sending host on a different interface from that on which it was sent, if
the host belongs to the destination group on that other interface. The
loopback control option has no effect on such delivery.

A host must become a member of a multicast group before it can receive datagrams
sent to the group. To join a multicast group, use the
IP_ADD_MEMBERSHIP option:

imr_interface should be
INADDR_ANY to choose the default multicast
interface, or the IP address of a particular multicast-capable interface if
the host is multihomed. Membership is associated with a single interface;
programs running on multihomed hosts may need to join the same group on more
than one interface. Up to
IP_MAX_MEMBERSHIPS (currently 4095)
memberships may be added on a single socket.

If proto is 0, the default protocol
IPPROTO_RAW is used for outgoing packets,
and only incoming packets destined for that protocol are received. If
proto is non-zero, that protocol number will
be used on outgoing packets and to filter incoming packets.

Outgoing packets automatically have an IP header prepended to them (based on the
destination address and the protocol number the socket is created with),
unless the IP_HDRINCL option has been set.
Incoming packets are received with IP header and options intact.

IP_HDRINCL indicates the complete IP header
is included with the data and may be used only with the
SOCK_RAW type.

Additionally note that starting with OpenBSD 2.1, the
ip_off and
ip_len fields are in network byte order. If
the header source address is set to
INADDR_ANY, the kernel will choose an
appropriate address.