1ip(7P) Protocols ip(7P)
2
6 ip, IP - Internet Protocol
7
9 #include <sys/socket.h>
10 #include <netinet/in.h>
13 s = socket(AF_INET, SOCK_RAW, proto);
16 t = t_open ("/dev/rawip", O_RDWR);
19
22 IP is the internetwork datagram delivery protocol that is central to
23 the Internet protocol family. Programs may use IP through higher-level
24 protocols such as the Transmission Control Protocol (TCP) or the User
25 Datagram Protocol (UDP), or may interface directly to IP. See tcp(7P)
26 and udp(7P). Direct access may be by means of the socket interface,
27 using a "raw socket," or by means of the Transport Level Interface
28 (TLI). The protocol options defined in the IP specification may be set
29 in outgoing datagrams.
30 Packets sent to or from this system may be subject to IPsec policy. See
33 ipsec(7P) for more information.
34
36 The STREAMS driver /dev/rawip is the TLI transport provider that pro‐
37 vides raw access to IP.
38 Raw IP sockets are connectionless and are normally used with the
41 sendto() and recvfrom() calls (see send(3SOCKET) and recv(3SOCKET)),
42 although the connect(3SOCKET) call may also be used to fix the destina‐
43 tion for future datagram. In this case, the read(2) or recv(3SOCKET)
44 and write(2) or send(3SOCKET) calls may be used. If proto is
45 IPPROTO_RAW or IPPROTO_IGMP, the application is expected to include a
46 complete IP header when sending. Otherwise, that protocol number will
47 be set in outgoing datagrams and used to filter incoming datagrams and
48 an IP header will be generated and prepended to each outgoing datagram.
49 In either case, received datagrams are returned with the IP header and
50 options intact.
51 If an application uses IP_HDRINCL and provides the IP header contents,
54 the IP stack does not modify the following supplied fields under any
55 conditions: Type of Service, DF Flag, Protocol, and Destination
56 Address. The IP Options and IHL fields are set by use of IP_OPTIONS,
57 and Total Length is updated to include any options. Version is set to
58 the default. Identification is chosen by the normal IP ID selection
59 logic. The source address is updated if none was specified and the TTL
60 is changed if the packet has a broadcast destination address. Since an
61 applicaton cannot send down fragments (as IP assigns the IP ID), Frag‐
62 ment Offset is always 0. The IP Checksum field is computed by IP. None
63 of the data beyond the IP header are changed, including the applica‐
64 tion-provided transport header.
65 The socket options supported at the IP level are:
68 IP_OPTIONS IP options for outgoing datagrams. This socket
70 option may be used to set IP options to be
71 included in each outgoing datagram. IP options to
72 be sent are set with setsockopt() (see getsock‐
73 opt(3SOCKET)). The getsockopt(3SOCKET) call
74 returns the IP options set in the last setsock‐
75 opt() call. IP options on received datagrams are
76 visible to user programs only using raw IP sock‐
77 ets. The format of IP options given in setsock‐
78 opt() matches those defined in the IP specifica‐
79 tion with one exception: the list of addresses
80 for the source routing options must include the
81 first-hop gateway at the beginning of the list of
82 gateways. The first-hop gateway address will be
83 extracted from the option list and the size
84 adjusted accordingly before use. IP options may
85 be used with any socket type in the Internet fam‐
86 ily.
87 IP_SEC_OPT Enable or obtain IPsec security settings for this
90 socket. For more details on the protection ser‐
91 vices of IPsec, see ipsec(7P).
92 IP_ADD_MEMBERSHIP Join a multicast group.
95 IP_DROP_MEMBERSHIP Leave a multicast group.
98 IP_BOUND_IF Limit reception and transmission of packets to
101 this interface. Takes an integer as an argument.
102 The integer is the selected interface index.
103 The following options take in_pktinfo_t as the parameter:
107 IP_PKTINFO
109 Set the source address and/or transmit interface of the packet(s).
111 Note that the IP_BOUND_IF socket option takes precedence over the
112 interface index passed in IP_PKTINFO.
113 struct in_pktinfo {
115 unsigned int ipi_ifindex;/* send/recv interface index */
116 struct in_addr ipi_spec_dst;/* matched source addr. */
117 struct in_addr ipi_addr;/* src/dst addr. in IP hdr */
118 } in_pktinfo_t;
119 When passed in (on transmit) via ancillary data with IP_PKTINFO,
121 ipi_spec_dst is used as the source address and ipi_ifindex is used
122 as the interface index to send the packet out.
123 IP_RECVPKTINFO
126 Enable/disable receipt of the index of the interface the packet
128 arrived on, the local address that was matched for reception, and
129 the inbound packet's actual destination address. Takes boolean as
130 the parameter. Returns struct in_pktinfo_t as ancillary data.
131 The following options take a struct ip_mreq as the parameter. The
135 structure contains a multicast address which must be set to the CLASS-D
136 IP multicast address and an interface address. Normally the interface
137 address is set to INADDR_ANY which causes the kernel to choose the
138 interface on which to join.
139 IP_BLOCK_SOURCE Block multicast packets whose source
141 address matches the given source address.
142 The specified group must be joined previ‐
143 ously using IP_ADD_MEMBERSHIP or
144 MCAST_JOIN_GROUP.
145 IP_UNBLOCK_SOURCE Unblock (begin receiving) multicast pack‐
148 ets which were previously blocked using
149 IP_BLOCK_SOURCE.
150 IP_ADD_SOURCE_MEMBERSHIP Begin receiving packets for the given mul‐
153 ticast group whose source address matches
154 the specified address.
155 IP_DROP_SOURCE_MEMBERSHIP Stop receiving packets for the given mul‐
158 ticast group whose source address matches
159 the specified address.
160 The following options take a struct ip_mreq_source as the parameter.
164 The structure contains a multicast address (which must be set to the
165 CLASS-D IP multicast address), an interface address, and a source
166 address.
167 MCAST_JOIN_GROUP Join a multicast group. Functionally equiv‐
169 alent to IP_ADD_MEMBERSHIP.
170 MCAST_BLOCK_SOURCE Block multicast packets whose source
173 address matches the given source address.
174 The specified group must be joined previ‐
175 ously using IP_ADD_MEMBERSHIP or
176 MCAST_JOIN_GROUP.
177 MCAST_UNBLOCK_SOURCE Unblock (begin receiving) multicast packets
180 which were previously blocked using
181 MCAST_BLOCK_SOURCE.
182 MCAST_LEAVE_GROUP Leave a multicast group. Functionally
185 equivalent to IP_DROP_MEMBERSHIP.
186 MCAST_JOIN_SOURCE_GROUP Begin receiving packets for the given mul‐
189 ticast group whose source address matches
190 the specified address.
191 MCAST_LEAVE_SOURCE_GROUP Stop receiving packets for the given multi‐
194 cast group whose source address matches the
195 specified address.
196 The following options take a struct group_req or struct
200 group_source_req as the parameter. The `group_req structure contains an
201 interface index and a multicast address which must be set to the CLASS-
202 D multicast address. The group_source_req structure is used for those
203 options which include a source address. It contains an interface index,
204 multicast address, and source address.
205 IP_MULTICAST_IF The outgoing interface for multicast packets. This
207 option takes a struct in_addr as an argument, and
208 it selects that interface for outgoing IP multi‐
209 cast packets. If the address specified is
210 INADDR_ANY, it uses the unicast routing table to
211 select the outgoing interface (which is the
212 default behavior).
213 IP_MULTICAST_TTL Time to live for multicast datagrams. This option
216 takes an unsigned character as an argument. Its
217 value is the TTL that IP uses on outgoing multi‐
218 cast datagrams. The default is 1.
219 IP_MULTICAST_LOOP Loopback for multicast datagrams. Normally multi‐
222 cast datagrams are delivered to members on the
223 sending host (or sending zone). Setting the
224 unsigned character argument to 0 causes the oppo‐
225 site behavior, meaning that when multiple zones
226 are present, the datagrams are delivered to all
227 zones except the sending zone.
228 IP_RECVIF Receive the inbound interface index.
231 IP_TOS This option takes an integer argument as its input
234 value. The least significant 8 bits of the value
235 are used to set the Type Of Service field in the
236 IP header of the outgoing packets.
237 IP_NEXTHOP This option specifies the address of the onlink
240 nexthop for traffic originating from that socket.
241 It causes the routing table to be bypassed and
242 outgoing traffic is sent directly to the specified
243 nexthop. This option takes an ipaddr_t argument
244 representing the IPv4 address of the nexthop as
245 the input value. The IP_NEXTHOP option takes
246 precedence over IPOPT_LSRR. IP_BOUND_IF and
247 SO_DONTROUTE take precedence over IP_NEXTHOP. This
248 option has no meaning for broadcast and multicast
249 packets. The application must ensure that the
250 specified nexthop is alive. An application may
251 want to specify the IP_NEXTHOP option on a TCP
252 listener socket only for incoming requests to a
253 particular IP address. In this case, it must avoid
254 binding the socket to INADDR_ANY and instead must
255 bind the listener socket to the specific IP
256 address. In addition, typically the application
257 may want the incoming and outgoing interface to be
258 the same. In this case, the application must
259 select a suitable nexthop that is onlink and
260 reachable via the desired interface and do a set‐
261 sockopt (IP_NEXTHOP) on it. Then it must bind to
262 the IP address of the desired interface. Setting
263 the IP_NEXTHOP option requires the
264 PRIV_SYS_NET_CONFIG privilege.
265 The multicast socket options (IP_MULTICAST_IF, IP_MULTICAST_TTL,
269 IP_MULTICAST_LOOP and IP_RECVIF) can be used with any datagram socket
270 type in the Internet family.
271 At the socket level, the socket option SO_DONTROUTE may be applied.
274 This option forces datagrams being sent to bypass routing and forward‐
275 ing by forcing the IP Time To Live field to 1, meaning that the packet
276 will not be forwarded by routers.
277 Raw IP datagrams can also be sent and received using the TLI connec‐
280 tionless primitives.
281 Datagrams flow through the IP layer in two directions: from the network
284 up to user processes and from user processes down to the network. Using
285 this orientation, IP is layered above the network interface drivers and
286 below the transport protocols such as UDP and TCP. The Internet Control
287 Message Protocol (ICMP) is logically a part of IP. See icmp(7P).
288 IP provides for a checksum of the header part, but not the data part,
291 of the datagram. The checksum value is computed and set in the process
292 of sending datagrams and checked when receiving datagrams.
293 IP options in received datagrams are processed in the IP layer accord‐
296 ing to the protocol specification. Currently recognized IP options
297 include: security, loose source and record route (LSRR), strict source
298 and record route (SSRR), record route, and internet timestamp.
299 By default, the IP layer will not forward IPv4 packets that are not
302 addressed to it. This behavior can be overridden by using routeadm(1M)
303 to enable the ipv4-forwarding option. IPv4 forwarding is configured at
304 boot time based on the setting of routeadm(1M)'s ipv4-forwarding
305 option.
306 For backwards compatibility, IPv4 forwarding can be enabled or disabled
309 using ndd(1M)'s ip_forwarding variable. It is set to 1 if IPv4 for‐
310 warding is enabled, or 0 if it is disabled.
311 Additionally, finer-grained forwarding can be configured in IP. Each
314 interface can be configured to forward IP packets by setting the
315 IFF_ROUTER interface flag. This flag can be set and cleared using
316 ifconfig(1M)'s router and router options. If an interface's IFF_ROUTER
317 flag is set, packets can be forwarded to or from the interface. If it
318 is clear, packets will neither be forwarded from this interface to oth‐
319 ers, nor forwarded to this interface. Setting the ip_forwarding vari‐
320 able sets all of the IPv4 interfaces' IFF_ROUTER flags.
321 For backwards compatibility, each interface creates an <ifname>:ip_for‐
324 warding /dev/ip variable that can be modified using ndd(1M). An inter‐
325 face's :ip_forwarding ndd variable is a boolean variable that mirrors
326 the status of its IFF_ROUTER interface flag. It is set to 1 if the flag
327 is set, or 0 if it is clear. This interface specific <ifname> :ip_for‐
328 warding ndd variable is obsolete and may be removed in a future release
329 of Solaris. The ifconfig(1M) router and -router interfaces are pre‐
330 ferred.
331 The IP layer sends an ICMP message back to the source host in many
334 cases when it receives a datagram that can not be handled. A "time
335 exceeded" ICMP message is sent if the "time to live" field in the IP
336 header drops to zero in the process of forwarding a datagram. A "desti‐
337 nation unreachable" message is sent if a datagram can not be forwarded
338 because there is no route to the final destination, or if it can not be
339 fragmented. If the datagram is addressed to the local host but is des‐
340 tined for a protocol that is not supported or a port that is not in
341 use, a destination unreachable message is also sent. The IP layer may
342 send an ICMP "source quench" message if it is receiving datagrams too
343 quickly. ICMP messages are only sent for the first fragment of a frag‐
344 mented datagram and are never returned in response to errors in other
345 ICMP messages.
346 The IP layer supports fragmentation and reassembly. Datagrams are frag‐
349 mented on output if the datagram is larger than the maximum transmis‐
350 sion unit (MTU) of the network interface. Fragments of received data‐
351 grams are dropped from the reassembly queues if the complete datagram
352 is not reconstructed within a short time period.
353 Errors in sending discovered at the network interface driver layer are
356 passed by IP back up to the user process.
357 Multi-Data Transmit allows more than one packet to be sent from the IP
360 module to another in a given call, thereby reducing the per-packet pro‐
361 cessing costs. The behavior of Multi-Data Transmit can be overrideen by
362 using ndd(1M) to set the /dev/ip variable, ip_multidata_outbound to 0.
363 Note, the IP module will only initiate Multi-Data Transmit if the net‐
364 work interface driver supports it.
365
367 Through the netinfo framework, this driver provides the following
368 packet events:
369 Physical in Packets received on a network interface from an exter‐
371 nal source.
372 Physical out Packets to be sent out a network interface.
375 Forwarding Packets being forwarded through this host to another
378 network.
379 loopback in Packets that have been sent by a local application to
382 another.
383 loopback out Packets about to be received by a local application
386 from another.
387 Currently, only a single function may be registered for each event. As
391 a result, if the slot for an event is already occupied by someone else,
392 a second attempt to register a callback fails.
393 To receive packet events in a kernel module, it is first necessary to
396 obtain a handle for either IPv4 or IPv6 traffic. This is achieved by
397 passing NHF_INET or NHF_INET6 through to a net_protocol_lookup() call.
398 The value returned from this call must then be passed into a call to
399 net_register_hook(), along with a description of the hook to add. For a
400 description of the structure passed through to the callback, please
401 see hook_pkt_event(9S). For IP packets, this structure is filled out as
402 follows:
403 hpe_ifp Identifier indicating the inbound interface for packets
405 received with the "physical in" event.
406 hpe_ofp Identifier indicating the outbound interface for packets
409 received with the "physical out" event.
410 hpe_hdr Pointer to the start of the IP header (not the ethernet
413 header).
414 hpe_mp Pointer to the start of the mblk_t chain containing the IP
417 packet.
418 hpe_mb Pointer to the mblk_t with the IP header in it.
421
424 In addition to events describing packets as they move through the sys‐
425 tem, it is also possible to receive notification of events relating to
426 network interfaces. These events are all reported back through the same
427 callback. The list of events is as follows:
428 plumb A new network interface has been instantiated.
430 unplumb A network interface is no longer associated with this
433 protocol.
434 up At least one logical interface is now ready to
437 receive packets.
438 down There are no logical interfaces expecting to receive
441 packets.
442 address change An address has changed on a logical interface.
445
448 ifconfig(1M), routeadm(1M), ndd(1M), read(2), write(2), bind(3SOCKET),
449 connect(3SOCKET), getsockopt(3SOCKET), recv(3SOCKET), send(3SOCKET),
450 defaultrouter(4), icmp(7P), if_tcp(7P), inet(7P), ip6(7P), ipsec(7P),
451 routing(7P), tcp(7P), udp(7P), net_hook_register(9F),
452 hook_pkt_event(9S)
453 Braden, R., RFC 1122, Requirements for Internet Hosts − Communication
456 Layers, Information Sciences Institute, University of Southern Califor‐
457 nia, October 1989.
458 Postel, J., RFC 791, Internet Protocol − DARPA Internet Program Proto‐
461 col Specification, Information Sciences Institute, University of South‐
462 ern California, September 1981.
463
465 A socket operation may fail with one of the following errors returned:
466 EACCES A bind() operation was attempted with a "reserved"
468 port number and the effective user ID of the process
469 was not the privileged user.
470 Setting the IP_NEXTHOP was attempted by a process
472 lacking the PRIV_SYS_NET_CONFIG privilege.
473 EADDRINUSE A bind() operation was attempted on a socket with a
476 network address/port pair that has already been bound
477 to another socket.
478 EADDRNOTAVAIL A bind() operation was attempted for an address that
481 is not configured on this machine.
482 EINVAL A sendmsg() operation with a non-NULL msg_accrights
485 was attempted.
486 EINVAL A getsockopt() or setsockopt() operation with an
489 unknown socket option name was given.
490 EINVAL A getsockopt() or setsockopt() operation was attempted
493 with the IP option field improperly formed; an option
494 field was shorter than the minimum value or longer
495 than the option buffer provided.
496 EISCONN A connect() operation was attempted on a socket on
499 which a connect() operation had already been per‐
500 formed, and the socket could not be successfully dis‐
501 connected before making the new connection.
502 EISCONN A sendto() or sendmsg() operation specifying an
505 address to which the message should be sent was
506 attempted on a socket on which a connect() operation
507 had already been performed.
508 EMSGSIZE A send(), sendto(), or sendmsg() operation was
511 attempted to send a datagram that was too large for an
512 interface, but was not allowed to be fragmented (such
513 as broadcasts).
514 ENETUNREACH An attempt was made to establish a connection by means
517 of connect(), or to send a datagram by means of
518 sendto() or sendmsg(), where there was no matching
519 entry in the routing table; or if an ICMP "destination
520 unreachable" message was received.
521 ENOTCONN A send() or write() operation, or a sendto() or
524 sendmsg() operation not specifying an address to which
525 the message should be sent, was attempted on a socket
526 on which a connect() operation had not already been
527 performed.
528 ENOBUFS The system ran out of memory for fragmentation buffers
531 or other internal data structures.
532 ENOBUFS SO_SNDBUF or SO_RCVBUF exceeds a system limit.
535 EINVAL Invalid length for IP_OPTIONS.
538 EHOSTUNREACH Invalid address for IP_MULTICAST_IF.
541 Invalid (offlink) nexthop address for IP_NEXTHOP.
543 EINVAL Not a multicast address for IP_ADD_MEMBERSHIP and
546 IP_DROP_MEMBERSHIP.
547 EADDRNOTAVAIL Bad interface address for IP_ADD_MEMBERSHIP and
550 IP_DROP_MEMBERSHIP.
551 EADDRINUSE Address already joined for IP_ADD_MEMBERSHIP.
554 ENOENT Address not joined for IP_DROP_MEMBERSHIP.
557 ENOPROTOOPT Invalid socket type.
560 EPERM No permissions.
563
566 Raw sockets should receive ICMP error packets relating to the protocol;
567 currently such packets are simply discarded.
568 Users of higher-level protocols such as TCP and UDP should be able to
571 see received IP options.
572SunOS 5.11 3 Dec 2008 ip(7P)