ip, IP - Internet Protocol
s = socket(AF_INET, SOCK_RAW, proto);
t = t_open ("/dev/rawip", O_RDWR);
IP is the internetwork datagram delivery protocol that is
central to the Internet protocol family. Programs may use
IP through higher-level protocols such as the Transmission
Control Protocol (TCP) or the User Datagram Protocol (UDP),
or may interface directly to IP. See tcp(7P) and udp(7P).
Direct access may be by means of the socket interface, using
a "raw socket," or by means of the Transport Level Interface
(TLI). The protocol options defined in the IP specification
may be set in outgoing datagrams.
Packets sent to or from this system may be subject to IPsec
policy; see ipsec(7P) for more information.
APPLICATION PROGRAMMING INTERFACE
The STREAMS driver /dev/rawip is the TLI transport provider
that provides raw access to IP.
Raw IP sockets are connectionless and are normally used with
the sendto() and recvfrom() calls (see send(3SOCKET) and
recv(3SOCKET)), although the connect(3SOCKET) call may also
be used to fix the destination for future datagram. In this
case, the read(2) or recv(3SOCKET) and write(2) or
send(3SOCKET) calls may be used. If proto is IPPROTO_RAW or
IPPROTO_IGMP, the application is expected to include a com-
plete IP header when sending. Otherwise, that protocol
number will be set in outgoing datagrams and used to filter
incoming datagrams and an IP header will be generated and
prepended to each outgoing datagram. In either case,
received datagrams are returned with the IP header and
If an application uses IP_HDRINCL and provides the IP header
contents, the IP stack does not modify the following sup-
plied fields under any conditions: Type of Service, DF Flag,
Protocol, and Destination Address. The IP Options and IHL
fields are set by use of IP_OPTIONS, and Total Length is
updated to include any options. Version is set to the
default. Identification is chosen by the normal IP ID
selection logic. The source address is updated if none was
specified and the TTL is changed if the packet has a broad-
cast destination address. Since an applicaton cannot send
down fragments (as IP assigns the IP ID), Fragment Offset is
always 0. The IP Checksum field is computed by IP. None of
the data beyond the IP header are changed, including the
application-provided transport header.
The socket options supported at the IP level are:
IP options for outgoing datagrams. This socket
option may be used to set IP options to be
included in each outgoing datagram. IP options
to be sent are set with setsockopt() (see
getsockopt(3SOCKET)). The getsockopt(3SOCKET)
call returns the IP options set in the last set-
sockopt() call. IP options on received datagrams
are visible to user programs only using raw IP
sockets. The format of IP options given in set-
sockopt() matches those defined in the IP specif-
ication with one exception: the list of addresses
for the source routing 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. IP options may
be used with any socket type in the Internet fam-
Enable or obtain IPsec security settings for this
socket. For more details on the protection ser-
vices of IPsec, see ipsec(7P).
Join a multicast group.
Leave a multicast group.
These options take a struct ip_mreq as the parameter. The
structure contains a multicast address which has to be set
to the CLASS-D IP multicast address, and an interface
address. Normally the interface address is set to INADDR_ANY
which causes the kernel to choose the interface to join on.
The outgoing interface for multicast packets.
This option takes a struct in_addr as an argu-
ment, and it selects that interface for outgoing
IP multicast packets. If the address specified
is INADDR_ANY, it will use the unicast routing
table to select the outgoing interface (which is
the default behavior).
Time to live for multicast datagrams. This option
takes an unsigned character as an argument. Its
value is the TTL that IP will use on outgoing
multicast datagrams. The default is 1.
Loopback for multicast datagrams. Normally multi-
cast datagrams are delivered to members on the
sending host. Setting the unsigned character
argument to 0 will cause the opposite behavior.
This option takes an integer argument as its
input value. The least significant 8 bits of the
value are used to set the Type Of Service field
in the IP header of the outgoing packets.
The multicast socket options can be used with any datagram
socket type in the Internet family.
At the socket level, the socket option SO_DONTROUTE may be
applied. This option forces datagrams being sent to bypass
routing and forwarding by forcing the IP Time To Live field
to 1, meaning that the packet will not be forwarded by
Raw IP datagrams can also be sent and received using the
TLI connectionless primitives.
Datagrams flow through the IP layer in two directions: from
the network up to user processes and from user processes
down to the network. Using this orientation, IP is layered
above the network interface drivers and below the transport
protocols such as UDP and TCP. The Internet Control Message
Protocol (ICMP) is logically a part of IP. See icmp(7P).
IP provides for a checksum of the header part, but not the
data part, of the datagram. The checksum value is computed
and set in the process of sending datagrams and checked when
IP options in received datagrams are processed in the IP
layer according to the protocol specification. Currently
recognized IP options include: security, loose source and
record route (LSRR), strict source and record route (SSRR),
record route, and internet timestamp.
The IP layer will normally act as a router when the machine
has two or more interfaces that are up, forwarding datagrams
that are not addressed to it, among other things. This
behavior can be overridden by using ndd(1M) to set the
/dev/ip variable, ip_forwarding. The value 0 means do not
forward; the value 1 means forward. The initialization
scripts set this value at boot time based on the number of
"up" interfaces, but will not turn on IP forwarding at all
if the file /etc/notrouter exists. See /etc/init.d/inetinit.
When the IP module is loaded, ip_forwarding is 0 and remains
o one non-DHCP-managed interface is up (the most common
o file /etc/notrouter exists and DHCP does not say that
IP forwarding is on
o file /etc/defaultrouter exists and DHCP does not say
IP forwarding is on
Otherwise, ip_forwarding is set to 1.
Additionally, finer-grained forwarding can be configured in
IP. Each interface creates an <ifname>:ip_forwarding
/dev/ip variable that can be modified using ndd(1M). If a
per-interface :ip_forwarding variable is set to 0, packets
will neither be forwarded from this interface to others, nor
forwarded to this interface. Setting the ip_forwarding
variable toggles all of the per-interface :ip_forwarding
variables to the setting of ip_forwarding.
The IP layer sends an ICMP message back to the source host
in many cases when it receives a datagram that can not be
handled. A "time exceeded" ICMP message is sent if the "time
to live" field in the IP header drops to zero in the process
of forwarding a datagram. A "destination unreachable" mes-
sage is sent if a datagram can not be forwarded because
there is no route to the final destination, or if it can not
be fragmented. If the datagram is addressed to the local
host but is destined for a protocol that is not supported or
a port that is not in use, a destination unreachable message
is also sent. The IP layer may send an ICMP "source quench"
message if it is receiving datagrams too quickly. ICMP mes-
sages are only sent for the first fragment of a fragmented
datagram and are never returned in response to errors in
other ICMP messages.
The IP layer supports fragmentation and reassembly.
Datagrams are fragmented on output if the datagram is larger
than the maximum transmission unit (MTU) of the network
interface. Fragments of received datagrams are dropped from
the reassembly queues if the complete datagram is not recon-
structed within a short time period.
Errors in sending discovered at the network interface driver
layer are passed by IP back up to the user process.
ndd(1M), read(2), write(2), bind(3SOCKET), connect(3SOCKET),
getsockopt(3SOCKET), recv(3SOCKET), send(3SOCKET), defaul-
trouter(4), icmp(7P), if_tcp(7P), inet(7P), ip6(7P),
ipsec(7P),routing(7P), tcp(7P), udp(7P)
Braden, R., RFC 1122, Requirements for Internet Hosts - Com-
munication Layers, Information Sciences Institute, Univer-
sity of Southern California, October 1989.
Postel, J., RFC 791, Internet Protocol - DARPA Internet Pro-
gram Protocol Specification, Information Sciences Institute,
University of Southern California, September 1981.
A socket operation may fail with one of the following errors
A bind() operation was attempted with a "reserved"
port number and the effective user ID of the process
was not the privileged user.
A bind() operation was attempted on a socket with a
network address/port pair that has already been bound
to another socket.
A bind() operation was attempted for an address that
is not configured on this machine.
A sendmsg() operation with a non-NULL msg_accrights
A getsockopt() or setsockopt() operation with an
unknown socket option name was given.
A getsockopt() or setsockopt() operation was attempted
with the IP option field improperly formed; an option
field was shorter than the minimum value or longer
than the option buffer provided.
A connect() operation was attempted on a socket on
which a connect() operation had already been per-
formed, and the socket could not be successfully
disconnected before making the new connection.
A sendto() or sendmsg() operation specifying an
address to which the message should be sent was
attempted on a socket on which a connect() operation
had already been performed.
A send(), sendto(), or sendmsg() operation was
attempted to send a datagram that was too large for an
interface, but was not allowed to be fragmented (such
An attempt was made to establish a connection by means
of connect(), or to send a datagram by means of
sendto() or sendmsg(), where there was no matching
entry in the routing table; or if an ICMP "destination
unreachable" message was received.
A send() or write() operation, or a sendto() or
sendmsg() operation not specifying an address to which
the message should be sent, was attempted on a socket
on which a connect() operation had not already been
The system ran out of memory for fragmentation buffers
or other internal data structures.
SO_SNDBUF or SO_RCVBUF exceeds a system limit.
Invalid length for IP_OPTIONS.
Invalid address for IP_MULTICAST_IF.
Not a multicast address for IP_ADD_MEMBERSHIP and
Bad interface address for IP_ADD_MEMBERSHIP and
Address already joined for IP_ADD_MEMBERSHIP.
Address not joined for IP_DROP_MEMBERSHIP.
EPERM No permissions.
Raw sockets should receive ICMP error packets relating to
the protocol; currently such packets are simply discarded.
Users of higher-level protocols such as TCP and UDP should
be able to see received IP options.
Man(1) output converted with