svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
ip(4p)
ip(4P) Network Protocols ip(4P)
NAME
ip, IP - Internet Protocol
SYNOPSIS
#include <sys/socket.h>
#include <netinet/in.h>
s = socket(AF_INET, SOCK_RAW, proto);
t = t_open ("/dev/rawip", O_RDWR);
DESCRIPTION
IP is the internetwork datagram delivery protocol that is central to
the Internet protocol family. Programs can use IP through higher-level
protocols such as the Transmission Control Protocol (TCP) or the User
Datagram Protocol (UDP), or can interface directly to IP. See tcp(4P)
and udp(4P). Direct access can be by means of the socket interface, us‐
ing a "raw socket," or by means of the Transport Level Interface (TLI).
The protocol options defined in the IP specification can be set in out‐
going datagrams.
Packets sent to or from this system can be subject to IPsec policy. See
ipsec(4P) for more information.
APPLICATION PROGRAMMING INTERFACE
The STREAMS driver /dev/rawip is the TLI transport provider that pro‐
vides raw access to IP.
Raw IP sockets are connectionless and are normally used with the
sendto() and recvfrom() calls (see send(3C) and recv(3C)), although the
connect(3C) call can also be used to fix the destination for future
datagram. In this case, the read(2) or recv(3C) and write(2) or
send(3C) calls can be used. If proto is IPPROTO_RAW or IPPROTO_IGMP,
the application is expected to include a complete IP header when send‐
ing. Otherwise, that protocol number is 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 data‐
grams are returned with the IP header and options intact.
If an application uses IP_HDRINCL and provides the IP header contents,
the IP stack does not modify the following supplied fields under any
conditions: Type of Service, DF Flag, Protocol, and Destination Ad‐
dress. 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 broadcast destination address. Since an ap‐
plication cannot send down fragments (as IP assigns the IP ID), Frag‐
ment Offset is always 0. The IP Checksum field is computed by IP. None
of the data beyond the IP header are changed, including the applica‐
tion-provided transport header.
The socket options supported at the IP level are:
IP_ADD_MEMBERSHIP Join a multicast group.
IP_BOUND_IF Limit reception and transmission of packets to
this interface. Takes an integer as an argument.
The integer is the selected interface index.
IP_DROP_MEMBERSHIP Leave a multicast group.
IP_OPTIONS IP options for outgoing datagrams. This socket
option can be used to set IP options to be in‐
cluded in each outgoing datagram. IP options to
be sent are set with setsockopt() (see getsock‐
opt(3C)). The getsockopt(3C) call returns the IP
options set in the last setsockopt() call. IP op‐
tions on received datagrams are visible to user
programs only using raw IP sockets. The format of
IP options given in setsockopt() matches those
defined in the IP specification with one excep‐
tion: the list of addresses for the source rout‐
ing 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 be‐
fore use. IP options can be used with any socket
type in the Internet family.
IP_RECVTTL Allow the user level application, mipagent, to
read the IP TTL (time to live) for an incoming
packet.
IP_SEC_OPT Enable or obtain IPsec security settings for this
socket. For more details on the protection ser‐
vices of IPsec, see ipsec(4P).
The following options take in_pktinfo_t as the parameter:
IP_PKTINFO
Set the source address and/or transmit interface of the packet(s).
The IP_BOUND_IF socket option takes precedence over the interface
index passed in IP_PKTINFO.
struct in_pktinfo {
unsigned int ipi_ifindex;/* send/recv interface index */
struct in_addr ipi_spec_dst;/* matched source addr. */
struct in_addr ipi_addr;/* src/dst addr. in IP hdr */
} in_pktinfo_t;
When passed in (on transmit) via ancillary data with IP_PKTINFO,
ipi_spec_dst is used as the source address and ipi_ifindex is used
as the interface index to send the packet out.
IP_RECVPKTINFO
Enable/disable receipt of the index of the interface the packet ar‐
rived on, the local address that was matched for reception, and the
inbound packet's actual destination address. Takes boolean as the
parameter. Returns struct in_pktinfo_t as ancillary data.
The following options take a struct ip_mreq as the parameter. The
structure contains a multicast address which must 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 in‐
terface on which to join.
IP_BLOCK_SOURCE Block multicast packets whose source ad‐
dress matches the given source address.
The specified group must be joined previ‐
ously using IP_ADD_MEMBERSHIP or
MCAST_JOIN_GROUP.
IP_UNBLOCK_SOURCE Unblock (begin receiving) multicast pack‐
ets which were previously blocked using
IP_BLOCK_SOURCE.
IP_ADD_SOURCE_MEMBERSHIP Begin receiving packets for the given mul‐
ticast group whose source address matches
the specified address.
IP_DROP_SOURCE_MEMBERSHIP Stop receiving packets for the given mul‐
ticast group whose source address matches
the specified address.
The following options take a struct ip_mreq_source as the parameter.
The structure contains a multicast address (which must be set to the
CLASS-D IP multicast address), an interface address, and a source ad‐
dress.
MCAST_JOIN_GROUP Join a multicast group. Functionally equiv‐
alent to IP_ADD_MEMBERSHIP.
MCAST_BLOCK_SOURCE Block multicast packets whose source ad‐
dress matches the given source address. The
specified group must be joined previously
using IP_ADD_MEMBERSHIP or
MCAST_JOIN_GROUP.
MCAST_UNBLOCK_SOURCE Unblock (begin receiving) multicast packets
which were previously blocked using
MCAST_BLOCK_SOURCE.
MCAST_LEAVE_GROUP Leave a multicast group. Functionally
equivalent to IP_DROP_MEMBERSHIP.
MCAST_JOIN_SOURCE_GROUP Begin receiving packets for the given mul‐
ticast group whose source address matches
the specified address.
MCAST_LEAVE_SOURCE_GROUP Stop receiving packets for the given multi‐
cast group whose source address matches the
specified address.
The following options take a struct group_req or struct
group_source_req as the parameter. The group_req structure contains an
interface index and a multicast address which must be set to the CLASS-
D multicast address. The group_source_req structure is used for those
options which include a source address. It contains an interface index,
multicast address, and source address.
IP_MULTICAST_IF The outgoing interface for multicast packets. This
option takes a struct in_addr as an argument, and
it selects that interface for outgoing IP multi‐
cast packets. If the address specified is IN‐
ADDR_ANY, it uses the unicast routing table to se‐
lect the outgoing interface (which is the default
behavior).
IP_MULTICAST_TTL Time to live for multicast datagrams. This option
takes an unsigned character as an argument. Its
value is the TTL that IP uses on outgoing multi‐
cast datagrams. The default is 1.
IP_MULTICAST_LOOP Loopback for multicast datagrams. Normally multi‐
cast datagrams are delivered to members on the
sending host (or sending zone). Setting the un‐
signed character argument to 0 causes the opposite
behavior, meaning that when multiple zones are
present, the datagrams are delivered to all zones
except the sending zone.
IP_RECVIF Receive the inbound interface index.
IP_TOS 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.
Note that this value will be overwritten if the
administrator configures flow DSCP marking using
flowadm(8), and the packet is classified to the
configured flow.
IP_DONTFRAG This option controls whether IP allows fragmenta‐
tion both locally (fragmenting the packets before
sending them out on the wire), and in the network
(whether or not the Don't Fragment flag is set in
the IPv4 header). Setting the option to any non-
zero value disables fragmentation. Setting the op‐
tion to zero enables fragmentation. When fragmen‐
tation is disabled then IP does not create any
Path MTU state on behalf of this socket.
IP_NEXTHOP This option specifies the address of the onlink
nexthop for traffic originating from that socket.
It causes the routing table to be bypassed and
outgoing traffic is sent directly to the specified
nexthop. This option takes an ipaddr_t argument
representing the IPv4 address of the nexthop as
the input value. The IP_NEXTHOP option takes
precedence over IPOPT_LSRR. IP_BOUND_IF and
SO_DONTROUTE take precedence over IP_NEXTHOP. This
option has no meaning for broadcast and multicast
packets. The application must ensure that the
specified nexthop is alive. An application can
want to specify the IP_NEXTHOP option on a TCP
listener socket only for incoming requests to a
particular IP address. In this case, it must avoid
binding the socket to INADDR_ANY and instead must
bind the listener socket to the specific IP ad‐
dress. In addition, typically the application can
want the incoming and outgoing interface to be the
same. In this case, the application must select a
suitable nexthop that is onlink and reachable via
the desired interface and do a setsockopt (IP_NEX‐
THOP) on it. Then it must bind to the IP address
of the desired interface. Setting the IP_NEXTHOP
option requires the PRIV_SYS_NET_CONFIG privilege.
The multicast socket options (IP_MULTICAST_IF, IP_MULTICAST_TTL,
IP_MULTICAST_LOOP and IP_RECVIF) can be used with any datagram socket
type in the Internet family.
At the socket level, the socket option SO_DONTROUTE can be applied.
This option forces datagrams being sent to bypass routing and forward‐
ing by forcing the IP Time To Live field to 1, meaning that the packet
is not be forwarded by routers.
Raw IP datagrams can also be sent and received using the TLI connec‐
tionless 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(4P).
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 receiving datagrams.
IP options in received datagrams are processed in the IP layer accord‐
ing to the protocol specification. Currently recognized IP options in‐
clude: security, loose source and record route (LSRR), strict source
and record route (SSRR), record route, and internet timestamp.
By default, the IP layer does not forward IPv4 packets that are not ad‐
dressed to it. This behavior can be overridden by using routeadm(8) to
enable the ipv4-forwarding option. IPv4 forwarding is configured at
boot time based on the setting of routeadm(8)'s ipv4-forwarding option.
IPv4 forwarding is configured at boot time based on the setting of
routeadm's ipv4-forwarding option. ipadm(8) can also be used to enable
ipv4 forwarding on a global basis. The ipadm set-prop subcommand along
with forwarding property is used to enable system-wide forwarding of
packets. The protocol for which forwarding needs to be enabled is spec‐
ified using the -m option. See ipadm(8).
Additionally, finer-grained forwarding can be configured in IP. Each
interface can be configured to forward IP packets by setting the
IFF_ROUTER interface flag. This flag can be set and cleared using if‐
config(8)'s router and router options. Also, the ipadm(8) set-ifprop
subcommand can be used to enable/disable per-interface ipv4 forwarding.
The ipadm set-ifprop interfaces are preferred. If an interface's
IFF_ROUTER flag is set, packets can be forwarded to or from the inter‐
face. If it is clear, packets are not forwarded from this interface to
others, nor forwarded to this interface. Setting the global forwarding
variable for ipv4, sets all of the IPv4 interfaces IFF_ROUTER flags.
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 ex‐
ceeded" 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 "desti‐
nation unreachable" message 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 des‐
tined 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 can
send an ICMP "source quench" message if it is receiving datagrams too
quickly. ICMP messages are only sent for the first fragment of a frag‐
mented datagram and are never returned in response to errors in other
ICMP messages.
The IP layer supports fragmentation and reassembly. Datagrams are frag‐
mented on output if the datagram is larger than the maximum transmis‐
sion unit (MTU) of the network interface. Fragments of received data‐
grams are dropped from the reassembly queues if the complete datagram
is not reconstructed 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.
PACKET EVENTS
Through the netinfo framework, this driver provides the following
packet events:
Physical in Packets received on a network interface from an exter‐
nal source.
Physical out Packets to be sent out a network interface.
Forwarding Packets being forwarded through this host to another
network.
loopback in Packets that have been sent by a local application to
another.
loopback out Packets about to be received by a local application
from another.
Currently, only a single function can be registered for each event. As
a result, if the slot for an event is already occupied by someone else,
a second attempt to register a callback fails.
To receive packet events in a kernel module, it is first necessary to
obtain a handle for either IPv4 or IPv6 traffic. This is achieved by
passing NHF_INET or NHF_INET6 through to a net_protocol_lookup() call.
The value returned from this call must then be passed into a call to
net_register_hook(), along with a description of the hook to add. For a
description of the structure passed through to the callback, see
hook_pkt_event(9S). For IP packets, this structure is filled out as
follows:
hpe_ifp Identifier indicating the inbound interface for packets re‐
ceived with the physical in event.
hpe_ofp Identifier indicating the outbound interface for packets re‐
ceived with the physical out event.
hpe_hdr Pointer to the start of the IP header (not the Ethernet
header).
hpe_mp Pointer to the start of the mblk_t chain containing the IP
packet.
hpe_mb Pointer to the mblk_t with the IP header in it.
NETWORK INTERFACE EVENTS
In addition to events describing packets as they move through the sys‐
tem, it is also possible to receive notification of events relating to
network interfaces. These events are all reported back through the same
callback. The list of events is as follows:
plumb A new network interface has been instantiated.
unplumb A network interface is no longer associated with this
protocol.
up At least one logical interface is now ready to re‐
ceive packets.
down There are no logical interfaces expecting to receive
packets.
address change An address has changed on a logical interface.
SEE ALSO
read(2), write(2), connect(3C), bind(3C), getsockopt(3C), recv(3C),
send(3C), icmp(4P), if_tcp(4P), inet(4P), ip6(4P), ipsec(4P), rout‐
ing(4P), tcp(4P), udp(4P), ifconfig(8), ipadm(8), ndd(8), routeadm(8),
net_hook_register(9F), hook_pkt_event(9S)
Braden, R., RFC 1122, Requirements for Internet Hosts − Communication
Layers, Information Sciences Institute, University of Southern Califor‐
nia, October 1989.
Postel, J., RFC 791, Internet Protocol − DARPA Internet Program Proto‐
col Specification, Information Sciences Institute, University of South‐
ern California, September 1981.
DIAGNOSTICS
A socket operation can fail with one of the following errors returned:
EACCES A bind() operation was attempted with a "reserved"
port number and the effective user ID of the process
was not the privileged user.
Setting the IP_NEXTHOP was attempted by a process
lacking the PRIV_SYS_NET_CONFIG privilege.
EADDRINUSE A bind() operation was attempted on a socket with a
network address/port pair that has already been bound
to another socket.
EADDRNOTAVAIL A bind() operation was attempted for an address that
is not configured on this machine.
EINVAL A sendmsg() operation with a non-NULL msg_accrights
was attempted.
EINVAL A getsockopt() or setsockopt() operation with an un‐
known socket option name was given.
EINVAL 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.
EISCONN 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 dis‐
connected before making the new connection.
EISCONN A sendto() or sendmsg() operation specifying an ad‐
dress to which the message should be sent was at‐
tempted on a socket on which a connect() operation had
already been performed.
EMSGSIZE A send(), sendto(), or sendmsg() operation was at‐
tempted to send a datagram that was too large for an
interface, but was not allowed to be fragmented (such
as broadcasts).
ENETUNREACH 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 en‐
try in the routing table; or if an ICMP destination
unreachable message was received.
ENOTCONN 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
performed.
ENOBUFS The system ran out of memory for fragmentation buffers
or other internal data structures.
ENOBUFS SO_SNDBUF or SO_RCVBUF exceeds a system limit.
EINVAL Invalid length for IP_OPTIONS.
EHOSTUNREACH Invalid address for IP_MULTICAST_IF.
Invalid (offlink) nexthop address for IP_NEXTHOP.
EINVAL Not a multicast address for IP_ADD_MEMBERSHIP and
IP_DROP_MEMBERSHIP.
EADDRNOTAVAIL Bad interface address for IP_ADD_MEMBERSHIP and
IP_DROP_MEMBERSHIP.
EADDRINUSE Address already joined for IP_ADD_MEMBERSHIP.
ENOENT Address not joined for IP_DROP_MEMBERSHIP.
ENOPROTOOPT Invalid socket type.
EPERM No permissions.
NOTES
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.
Oracle Solaris 11.4 11 May 2021 ip(4P)