xref: /netbsd-src/share/man/man4/ip.4 (revision d0fed6c87ddc40a8bffa6f99e7433ddfc864dd83)
1.\"	$NetBSD: ip.4,v 1.4 1997/01/12 00:59:51 thorpej Exp $
2.\"
3.\" Copyright (c) 1983, 1991, 1993
4.\"	The Regents of the University of California.  All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
10.\"    notice, this list of conditions and the following disclaimer.
11.\" 2. Redistributions in binary form must reproduce the above copyright
12.\"    notice, this list of conditions and the following disclaimer in the
13.\"    documentation and/or other materials provided with the distribution.
14.\" 3. All advertising materials mentioning features or use of this software
15.\"    must display the following acknowledgement:
16.\"	This product includes software developed by the University of
17.\"	California, Berkeley and its contributors.
18.\" 4. Neither the name of the University nor the names of its contributors
19.\"    may be used to endorse or promote products derived from this software
20.\"    without specific prior written permission.
21.\"
22.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
23.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
24.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
25.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
26.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
27.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
28.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
29.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
30.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
31.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
32.\" SUCH DAMAGE.
33.\"
34.\"     @(#)ip.4	8.2 (Berkeley) 11/30/93
35.\"
36.Dd November 30, 1993
37.Dt IP 4
38.Os BSD 4.2
39.Sh NAME
40.Nm ip
41.Nd Internet Protocol
42.Sh SYNOPSIS
43.Fd #include <sys/socket.h>
44.Fd #include <netinet/in.h>
45.Ft int
46.Fn socket AF_INET SOCK_RAW proto
47.Sh DESCRIPTION
48.Tn IP
49is the transport layer protocol used
50by the Internet protocol family.
51Options may be set at the
52.Tn IP
53level
54when using higher-level protocols that are based on
55.Tn IP
56(such as
57.Tn TCP
58and
59.Tn UDP ) .
60It may also be accessed
61through a
62.Dq raw socket
63when developing new protocols, or
64special-purpose applications.
65.Pp
66There are several
67.Tn IP-level
68.Xr setsockopt 2 / Ns
69.Xr getsockopt 2
70options.
71.Dv IP_OPTIONS
72may be used to provide
73.Tn IP
74options to be transmitted in the
75.Tn IP
76header of each outgoing packet
77or to examine the header options on incoming packets.
78.Tn IP
79options may be used with any socket type in the Internet family.
80The format of
81.Tn IP
82options to be sent is that specified by the
83.Tn IP
84protocol specification (RFC-791), with one exception:
85the list of addresses for Source Route options must include the first-hop
86gateway at the beginning of the list of gateways.
87The first-hop gateway address will be extracted from the option list
88and the size adjusted accordingly before use.
89To disable previously specified options,
90use a zero-length buffer:
91.Bd -literal
92setsockopt(s, IPPROTO_IP, IP_OPTIONS, NULL, 0);
93.Ed
94.Pp
95.Dv IP_TOS
96and
97.Dv IP_TTL
98may be used to set the type-of-service and time-to-live
99fields in the
100.Tn IP
101header for
102.Dv SOCK_STREAM
103and
104.Dv SOCK_DGRAM
105sockets. For example,
106.Bd -literal
107int tos = IPTOS_LOWDELAY;       /* see <netinet/in.h> */
108setsockopt(s, IPPROTO_IP, IP_TOS, &tos, sizeof(tos));
109
110int ttl = 60;                   /* max = 255 */
111setsockopt(s, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));
112.Ed
113.Pp
114If the
115.Dv IP_RECVDSTADDR
116option is enabled on a
117.Dv SOCK_DGRAM
118or
119.Dv SOCK_RAW
120socket,
121the
122.Xr recvmsg
123call will return the destination
124.Tn IP
125address for a
126.Tn UDP
127datagram.
128The msg_control field in the msghdr structure points to a buffer
129that contains a cmsghdr structure followed by the
130.Tn IP
131address.
132The cmsghdr fields have the following values:
133.Bd -literal
134cmsg_len = sizeof(struct in_addr)
135cmsg_level = IPPROTO_IP
136cmsg_type = IP_RECVDSTADDR
137.Ed
138.Pp
139If the
140.Dv IP_RECVIF
141option is enabled on a
142.Dv SOCK_DGRAM
143or
144.Dv SOCK_RAW
145socket,
146the
147.Xr recvmsg
148call will return a struct sockaddr_dl corresponding to
149the interface on which the packet was received.
150the msg_control field in the msghdr structure points to a buffer
151that contains a cmsghdr structure followed by the struct sockaddr_dl.
152The cmsghdr fields have the following values:
153.Bd -literal
154cmsg_len = sizeof(struct sockaddr_dl)
155cmsg_level = IPPROTO_IP
156cmsg_type = IP_RECVIF
157.Ed
158.Ss "Multicast Options"
159.Pp
160.Tn IP
161multicasting is supported only on
162.Dv AF_INET
163sockets of type
164.Dv SOCK_DGRAM
165and
166.Dv SOCK_RAW,
167and only on networks where the interface
168driver supports multicasting.
169.Pp
170The
171.Dv IP_MULTICAST_TTL
172option changes the time-to-live (TTL)
173for outgoing multicast datagrams
174in order to control the scope of the multicasts:
175.Bd -literal
176u_char ttl;	/* range: 0 to 255, default = 1 */
177setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));
178.Ed
179.sp
180Datagrams with a TTL of 1 are not forwarded beyond the local network.
181Multicast datagrams with a TTL of 0 will not be transmitted on any network,
182but may be delivered locally if the sending host belongs to the destination
183group and if multicast loopback has not been disabled on the sending socket
184(see below).  Multicast datagrams with TTL greater than 1 may be forwarded
185to other networks if a multicast router is attached to the local network.
186.Pp
187For hosts with multiple interfaces, each multicast transmission is
188sent from the primary network interface.
189The
190.Dv IP_MULTICAST_IF
191option overrides the default for
192subsequent transmissions from a given socket:
193.Bd -literal
194struct in_addr addr;
195setsockopt(s, IPPROTO_IP, IP_MULTICAST_IF, &addr, sizeof(addr));
196.Ed
197.sp
198where "addr" is the local
199.Tn IP
200address of the desired interface or
201.Dv INADDR_ANY
202to specify the default interface.
203An interface's local IP address and multicast capability can
204be obtained via the
205.Dv SIOCGIFCONF
206and
207.Dv SIOCGIFFLAGS
208ioctls.
209Normal applications should not need to use this option.
210.Pp
211If a multicast datagram is sent to a group to which the sending host itself
212belongs (on the outgoing interface), a copy of the datagram is, by default,
213looped back by the IP layer for local delivery.
214The
215.Dv IP_MULTICAST_LOOP
216option gives the sender explicit control
217over whether or not subsequent datagrams are looped back:
218.Bd -literal
219u_char loop;	/* 0 = disable, 1 = enable (default) */
220setsockopt(s, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop));
221.Ed
222.sp
223This option
224improves performance for applications that may have no more than one
225instance on a single host (such as a router demon), by eliminating
226the overhead of receiving their own transmissions.  It should generally not
227be used by applications for which there may be more than one instance on a
228single host (such as a conferencing program) or for which the sender does
229not belong to the destination group (such as a time querying program).
230.Pp
231A multicast datagram sent with an initial TTL greater than 1 may be delivered
232to the sending host on a different interface from that on which it was sent,
233if the host belongs to the destination group on that other interface.  The
234loopback control option has no effect on such delivery.
235.Pp
236A host must become a member of a multicast group before it can receive
237datagrams sent to the group.  To join a multicast group, use the
238.Dv IP_ADD_MEMBERSHIP
239option:
240.Bd -literal
241struct ip_mreq mreq;
242setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));
243.Ed
244.sp
245where
246.Fa mreq
247is the following structure:
248.Bd -literal
249struct ip_mreq {
250    struct in_addr imr_multiaddr; /* multicast group to join */
251    struct in_addr imr_interface; /* interface to join on */
252}
253.Ed
254.sp
255.Dv imr_interface
256should
257be
258.Dv INADDR_ANY
259to choose the default multicast interface,
260or the
261.Tn IP
262address of a particular multicast-capable interface if
263the host is multihomed.
264Membership is associated with a single interface;
265programs running on multihomed hosts may need to
266join the same group on more than one interface.
267Up to
268.Dv IP_MAX_MEMBERSHIPS
269(currently 20) memberships may be added on a
270single socket.
271.Pp
272To drop a membership, use:
273.Bd -literal
274struct ip_mreq mreq;
275setsockopt(s, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));
276.Ed
277.sp
278where
279.Fa mreq
280contains the same values as used to add the membership.
281Memberships are dropped when the socket is closed or the process exits.
282.\"-----------------------
283.Ss "Raw IP Sockets"
284.Pp
285Raw
286.Tn IP
287sockets are connectionless,
288and are normally used with the
289.Xr sendto
290and
291.Xr recvfrom
292calls, though the
293.Xr connect 2
294call may also be used to fix the destination for future
295packets (in which case the
296.Xr read 2
297or
298.Xr recv 2
299and
300.Xr write 2
301or
302.Xr send 2
303system calls may be used).
304.Pp
305If
306.Fa proto
307is 0, the default protocol
308.Dv IPPROTO_RAW
309is used for outgoing
310packets, and only incoming packets destined for that protocol
311are received.
312If
313.Fa proto
314is non-zero, that protocol number will be used on outgoing packets
315and to filter incoming packets.
316.Pp
317Outgoing packets automatically have an
318.Tn IP
319header prepended to
320them (based on the destination address and the protocol
321number the socket is created with),
322unless the
323.Dv IP_HDRINCL
324option has been set.
325Incoming packets are received with
326.Tn IP
327header and options intact.
328.Pp
329.Dv IP_HDRINCL
330indicates the complete IP header is included with the data
331and may be used only with the
332.Dv SOCK_RAW
333type.
334.Bd -literal
335#include <netinet/ip.h>
336
337int hincl = 1;                  /* 1 = on, 0 = off */
338setsockopt(s, IPPROTO_IP, IP_HDRINCL, &hincl, sizeof(hincl));
339.Ed
340.sp
341Unlike previous
342.Tn BSD
343releases, the program must set all
344the fields of the IP header, including the following:
345.Bd -literal
346ip->ip_v = IPVERSION;
347ip->ip_hl = hlen >> 2;
348ip->ip_id = 0;  /* 0 means kernel set appropriate value */
349ip->ip_off = offset;
350.Ed
351.sp .5
352If the header source address is set to
353.Dv INADDR_ANY,
354the kernel will choose an appropriate address.
355.Sh DIAGNOSTICS
356A socket operation may fail with one of the following errors returned:
357.Bl -tag -width [EADDRNOTAVAIL]
358.It Bq Er EISCONN
359when trying to establish a connection on a socket which
360already has one, or when trying to send a datagram with the destination
361address specified and the socket is already connected;
362.It Bq Er ENOTCONN
363when trying to send a datagram, but
364no destination address is specified, and the socket hasn't been
365connected;
366.It Bq Er ENOBUFS
367when the system runs out of memory for
368an internal data structure;
369.It Bq Er EADDRNOTAVAIL
370when an attempt is made to create a
371socket with a network address for which no network interface
372exists.
373.It Bq Er EACESS
374when an attempt is made to create
375a raw IP socket by a non-privileged process.
376.El
377.Pp
378The following errors specific to
379.Tn IP
380may occur when setting or getting
381.Tn IP
382options:
383.Bl -tag -width EADDRNOTAVAILxx
384.It Bq Er EINVAL
385An unknown socket option name was given.
386.It Bq Er EINVAL
387The IP option field was improperly formed;
388an option field was shorter than the minimum value
389or longer than the option buffer provided.
390.El
391.Sh SEE ALSO
392.Xr getsockopt 2 ,
393.Xr send 2 ,
394.Xr recv 2 ,
395.Xr intro 4 ,
396.Xr icmp 4 ,
397.Xr inet 4
398.Sh HISTORY
399The
400.Nm
401protocol appeared in
402.Bx 4.2 .
403