xref: /freebsd/share/man/man4/ip.4 (revision 6f5bc70a3ff25d174ded4288565c90e4488225c5)
1.\" Copyright (c) 1983, 1991, 1993
2.\"	The Regents of the University of California.  All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that the following conditions
6.\" are met:
7.\" 1. Redistributions of source code must retain the above copyright
8.\"    notice, this list of conditions and the following disclaimer.
9.\" 2. Redistributions in binary form must reproduce the above copyright
10.\"    notice, this list of conditions and the following disclaimer in the
11.\"    documentation and/or other materials provided with the distribution.
12.\" 3. All advertising materials mentioning features or use of this software
13.\"    must display the following acknowledgement:
14.\"	This product includes software developed by the University of
15.\"	California, Berkeley and its contributors.
16.\" 4. Neither the name of the University nor the names of its contributors
17.\"    may be used to endorse or promote products derived from this software
18.\"    without specific prior written permission.
19.\"
20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
30.\" SUCH DAMAGE.
31.\"
32.\"     @(#)ip.4	8.2 (Berkeley) 11/30/93
33.\" $FreeBSD$
34.\"
35.Dd June 14, 2004
36.Dt IP 4
37.Os
38.Sh NAME
39.Nm ip
40.Nd Internet Protocol
41.Sh SYNOPSIS
42.In sys/types.h
43.In sys/socket.h
44.In 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
69and
70.Xr getsockopt 2
71options.
72.Dv IP_OPTIONS
73may be used to provide
74.Tn IP
75options to be transmitted in the
76.Tn IP
77header of each outgoing packet
78or to examine the header options on incoming packets.
79.Tn IP
80options may be used with any socket type in the Internet family.
81The format of
82.Tn IP
83options to be sent is that specified by the
84.Tn IP
85protocol specification (RFC-791), with one exception:
86the list of addresses for Source Route options must include the first-hop
87gateway at the beginning of the list of gateways.
88The first-hop gateway address will be extracted from the option list
89and the size adjusted accordingly before use.
90To disable previously specified options,
91use a zero-length buffer:
92.Bd -literal
93setsockopt(s, IPPROTO_IP, IP_OPTIONS, NULL, 0);
94.Ed
95.Pp
96.Dv IP_TOS
97and
98.Dv IP_TTL
99may be used to set the type-of-service and time-to-live
100fields in the
101.Tn IP
102header for
103.Dv SOCK_STREAM , SOCK_DGRAM ,
104and certain types of
105.Dv SOCK_RAW
106sockets.
107For example,
108.Bd -literal
109int tos = IPTOS_LOWDELAY;       /* see <netinet/ip.h> */
110setsockopt(s, IPPROTO_IP, IP_TOS, &tos, sizeof(tos));
111
112int ttl = 60;                   /* max = 255 */
113setsockopt(s, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));
114.Ed
115.Pp
116If the
117.Dv IP_RECVDSTADDR
118option is enabled on a
119.Dv SOCK_DGRAM
120socket,
121the
122.Xr recvmsg 2
123call will return the destination
124.Tn IP
125address for a
126.Tn UDP
127datagram.
128The
129.Vt msg_control
130field in the
131.Vt msghdr
132structure points to a buffer
133that contains a
134.Vt cmsghdr
135structure followed by the
136.Tn IP
137address.
138The
139.Vt cmsghdr
140fields have the following values:
141.Bd -literal
142cmsg_len = sizeof(struct in_addr)
143cmsg_level = IPPROTO_IP
144cmsg_type = IP_RECVDSTADDR
145.Ed
146.Pp
147The source address to be used for outgoing
148.Tn UDP
149datagrams on a socket that is not bound to a specific
150.Tn IP
151address can be specified as ancillary data with a type code of
152.Dv IP_SENDSRCADDR .
153The msg_control field in the msghdr structure should point to a buffer
154that contains a
155.Vt cmsghdr
156structure followed by the
157.Tn IP
158address.
159The cmsghdr fields should have the following values:
160.Bd -literal
161cmsg_len = sizeof(struct in_addr)
162cmsg_level = IPPROTO_IP
163cmsg_type = IP_SENDSRCADDR
164.Ed
165.Pp
166For convenience,
167.Dv IP_SENDSRCADDR
168is defined to have the same value as
169.Dv IP_RECVDSTADDR ,
170so the
171.Dv IP_RECVDSTADDR
172control message from
173.Xr recvmsg 2
174can be used directly as a control message for
175.Xr sendmsg 2 .
176.Pp
177If the
178.Dv IP_ONESBCAST
179option is enabled on a
180.Dv SOCK_DGRAM
181or a
182.Dv SOCK_RAW
183socket, the destination address of outgoing
184broadcast datagrams on that socket will be forced
185to the undirected broadcast address,
186.Dv INADDR_BROADCAST ,
187before transmission.
188This is in contrast to the default behavior of the
189system, which is to transmit undirected broadcasts
190via the first network interface with the
191.Dv IFF_BROADCAST flag set.
192.Pp
193This option allows applications to choose which
194interface is used to transmit an undirected broadcast
195datagram.
196For example, the following code would force an
197undirected broadcast to be transmitted via the interface
198configured with the broadcast address 192.168.2.255:
199.Bd -literal
200char msg[512];
201struct sockaddr_in sin;
202u_char onesbcast = 1;	/* 0 = disable (default), 1 = enable */
203
204setsockopt(s, IPPROTO_IP, IP_ONESBCAST, &onesbcast, sizeof(onesbcast));
205sin.sin_addr.s_addr = inet_addr("192.168.2.255");
206sin.sin_port = htons(1234);
207sendto(s, msg, sizeof(msg), 0, &sin, sizeof(sin));
208.Ed
209.Pp
210It is the application's responsibility to set the
211.Dv IP_TTL option
212to an appropriate value in order to prevent broadcast storms.
213The application must have sufficient credentials to set the
214.Dv SO_BROADCAST
215socket level option, otherwise the
216.Dv IP_ONESBCAST option has no effect.
217.Pp
218If the
219.Dv IP_RECVTTL
220option is enabled on a
221.Dv SOCK_DGRAM
222socket, the
223.Xr recvmsg 2
224call will return the
225.Tn IP
226.Tn TTL
227(time to live) field for a
228.Tn UDP
229datagram.
230The msg_control field in the msghdr structure points to a buffer
231that contains a cmsghdr structure followed by the
232.Tn TTL .
233The cmsghdr fields have the following values:
234.Bd -literal
235cmsg_len = sizeof(u_char)
236cmsg_level = IPPROTO_IP
237cmsg_type = IP_RECVTTL
238.Ed
239.Pp
240If the
241.Dv IP_RECVIF
242option is enabled on a
243.Dv SOCK_DGRAM
244socket, the
245.Xr recvmsg 2
246call returns a
247.Vt "struct sockaddr_dl"
248corresponding to the interface on which the
249packet was received.
250The
251.Va msg_control
252field in the
253.Vt msghdr
254structure points to a buffer that contains a
255.Vt cmsghdr
256structure followed by the
257.Vt "struct sockaddr_dl" .
258The
259.Vt cmsghdr
260fields have the following values:
261.Bd -literal
262cmsg_len = sizeof(struct sockaddr_dl)
263cmsg_level = IPPROTO_IP
264cmsg_type = IP_RECVIF
265.Ed
266.Pp
267.Dv IP_PORTRANGE
268may be used to set the port range used for selecting a local port number
269on a socket with an unspecified (zero) port number.
270It has the following
271possible values:
272.Bl -tag -width IP_PORTRANGE_DEFAULT
273.It Dv IP_PORTRANGE_DEFAULT
274use the default range of values, normally
275.Dv IPPORT_HIFIRSTAUTO
276through
277.Dv IPPORT_HILASTAUTO .
278This is adjustable through the sysctl setting:
279.Va net.inet.ip.portrange.first
280and
281.Va net.inet.ip.portrange.last .
282.It Dv IP_PORTRANGE_HIGH
283use a high range of values, normally
284.Dv IPPORT_HIFIRSTAUTO
285and
286.Dv IPPORT_HILASTAUTO .
287This is adjustable through the sysctl setting:
288.Va net.inet.ip.portrange.hifirst
289and
290.Va net.inet.ip.portrange.hilast .
291.It Dv IP_PORTRANGE_LOW
292use a low range of ports, which are normally restricted to
293privileged processes on
294.Ux
295systems.
296The range is normally from
297.Dv IPPORT_RESERVED
298\- 1 down to
299.Li IPPORT_RESERVEDSTART
300in descending order.
301This is adjustable through the sysctl setting:
302.Va net.inet.ip.portrange.lowfirst
303and
304.Va net.inet.ip.portrange.lowlast .
305.El
306.Pp
307The range of privileged ports which only may be opened by
308root-owned processes may be modified by the
309.Va net.inet.ip.portrange.reservedlow
310and
311.Va net.inet.ip.portrange.reservedhigh
312sysctl settings.
313The values default to the traditional range,
3140 through
315.Dv IPPORT_RESERVED
316\- 1
317(0 through 1023), respectively.
318Note that these settings do not affect and are not accounted for in the
319use or calculation of the other
320.Va net.inet.ip.portrange
321values above.
322Changing these values departs from
323.Ux
324tradition and has security
325consequences that the administrator should carefully evaluate before
326modifying these settings.
327.Pp
328Ports are allocated at random within the specified port range in order
329to increase the difficulty of random spoofing attacks.  In scenarios
330such as benchmarking, this behavior may be undesireable.  In these
331cases,
332.Va net.inet.ip.portrange.randomized
333can be used to toggle randomization off.
334.Ss "Multicast Options"
335.Pp
336.Tn IP
337multicasting is supported only on
338.Dv AF_INET
339sockets of type
340.Dv SOCK_DGRAM
341and
342.Dv SOCK_RAW ,
343and only on networks where the interface
344driver supports multicasting.
345.Pp
346The
347.Dv IP_MULTICAST_TTL
348option changes the time-to-live (TTL)
349for outgoing multicast datagrams
350in order to control the scope of the multicasts:
351.Bd -literal
352u_char ttl;	/* range: 0 to 255, default = 1 */
353setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));
354.Ed
355.Pp
356Datagrams with a TTL of 1 are not forwarded beyond the local network.
357Multicast datagrams with a TTL of 0 will not be transmitted on any network,
358but may be delivered locally if the sending host belongs to the destination
359group and if multicast loopback has not been disabled on the sending socket
360(see below).
361Multicast datagrams with TTL greater than 1 may be forwarded
362to other networks if a multicast router is attached to the local network.
363.Pp
364For hosts with multiple interfaces, each multicast transmission is
365sent from the primary network interface.
366The
367.Dv IP_MULTICAST_IF
368option overrides the default for
369subsequent transmissions from a given socket:
370.Bd -literal
371struct in_addr addr;
372setsockopt(s, IPPROTO_IP, IP_MULTICAST_IF, &addr, sizeof(addr));
373.Ed
374.Pp
375where "addr" is the local
376.Tn IP
377address of the desired interface or
378.Dv INADDR_ANY
379to specify the default interface.
380An interface's local IP address and multicast capability can
381be obtained via the
382.Dv SIOCGIFCONF
383and
384.Dv SIOCGIFFLAGS
385ioctls.
386Normal applications should not need to use this option.
387.Pp
388If a multicast datagram is sent to a group to which the sending host itself
389belongs (on the outgoing interface), a copy of the datagram is, by default,
390looped back by the IP layer for local delivery.
391The
392.Dv IP_MULTICAST_LOOP
393option gives the sender explicit control
394over whether or not subsequent datagrams are looped back:
395.Bd -literal
396u_char loop;	/* 0 = disable, 1 = enable (default) */
397setsockopt(s, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop));
398.Ed
399.Pp
400This option
401improves performance for applications that may have no more than one
402instance on a single host (such as a router daemon), by eliminating
403the overhead of receiving their own transmissions.
404It should generally not
405be used by applications for which there may be more than one instance on a
406single host (such as a conferencing program) or for which the sender does
407not belong to the destination group (such as a time querying program).
408.Pp
409A multicast datagram sent with an initial TTL greater than 1 may be delivered
410to the sending host on a different interface from that on which it was sent,
411if the host belongs to the destination group on that other interface.
412The loopback control option has no effect on such delivery.
413.Pp
414A host must become a member of a multicast group before it can receive
415datagrams sent to the group.
416To join a multicast group, use the
417.Dv IP_ADD_MEMBERSHIP
418option:
419.Bd -literal
420struct ip_mreq mreq;
421setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));
422.Ed
423.Pp
424where
425.Fa mreq
426is the following structure:
427.Bd -literal
428struct ip_mreq {
429    struct in_addr imr_multiaddr; /* IP multicast address of group */
430    struct in_addr imr_interface; /* local IP address of interface */
431}
432.Ed
433.Pp
434.Dv imr_interface
435should
436be
437.Dv INADDR_ANY
438to choose the default multicast interface,
439or the
440.Tn IP
441address of a particular multicast-capable interface if
442the host is multihomed.
443Membership is associated with a single interface;
444programs running on multihomed hosts may need to
445join the same group on more than one interface.
446Up to
447.Dv IP_MAX_MEMBERSHIPS
448(currently 20) memberships may be added on a
449single socket.
450.Pp
451To drop a membership, use:
452.Bd -literal
453struct ip_mreq mreq;
454setsockopt(s, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));
455.Ed
456.Pp
457where
458.Fa mreq
459contains the same values as used to add the membership.
460Memberships are dropped when the socket is closed or the process exits.
461.\"-----------------------
462.Ss "Raw IP Sockets"
463.Pp
464Raw
465.Tn IP
466sockets are connectionless,
467and are normally used with the
468.Xr sendto 2
469and
470.Xr recvfrom 2
471calls, though the
472.Xr connect 2
473call may also be used to fix the destination for future
474packets (in which case the
475.Xr read 2
476or
477.Xr recv 2
478and
479.Xr write 2
480or
481.Xr send 2
482system calls may be used).
483.Pp
484If
485.Fa proto
486is 0, the default protocol
487.Dv IPPROTO_RAW
488is used for outgoing
489packets, and only incoming packets destined for that protocol
490are received.
491If
492.Fa proto
493is non-zero, that protocol number will be used on outgoing packets
494and to filter incoming packets.
495.Pp
496Outgoing packets automatically have an
497.Tn IP
498header prepended to
499them (based on the destination address and the protocol
500number the socket is created with),
501unless the
502.Dv IP_HDRINCL
503option has been set.
504Incoming packets are received with
505.Tn IP
506header and options intact.
507.Pp
508.Dv IP_HDRINCL
509indicates the complete IP header is included with the data
510and may be used only with the
511.Dv SOCK_RAW
512type.
513.Bd -literal
514#include <netinet/in_systm.h>
515#include <netinet/ip.h>
516
517int hincl = 1;                  /* 1 = on, 0 = off */
518setsockopt(s, IPPROTO_IP, IP_HDRINCL, &hincl, sizeof(hincl));
519.Ed
520.Pp
521Unlike previous
522.Bx
523releases, the program must set all
524the fields of the IP header, including the following:
525.Bd -literal
526ip->ip_v = IPVERSION;
527ip->ip_hl = hlen >> 2;
528ip->ip_id = 0;  /* 0 means kernel set appropriate value */
529ip->ip_off = offset;
530.Ed
531.Pp
532The ip_len and ip_off fields
533.Em must be provided in host byte order .
534All other fields must be provided in network byte order.
535See
536.Xr byteorder 4
537for more information on network byte order.
538If the ip_id field is set to 0, then the kernel will choose an
539appopriate value.
540If the header source address is set to
541.Dv INADDR_ANY ,
542the kernel will choose an appropriate address.
543.Sh ERRORS
544A socket operation may fail with one of the following errors returned:
545.Bl -tag -width Er
546.It Bq Er EISCONN
547when trying to establish a connection on a socket which
548already has one, or when trying to send a datagram with the destination
549address specified and the socket is already connected;
550.It Bq Er ENOTCONN
551when trying to send a datagram, but
552no destination address is specified, and the socket hasn't been
553connected;
554.It Bq Er ENOBUFS
555when the system runs out of memory for
556an internal data structure;
557.It Bq Er EADDRNOTAVAIL
558when an attempt is made to create a
559socket with a network address for which no network interface
560exists.
561.It Bq Er EACCES
562when an attempt is made to create
563a raw IP socket by a non-privileged process.
564.El
565.Pp
566The following errors specific to
567.Tn IP
568may occur when setting or getting
569.Tn IP
570options:
571.Bl -tag -width Er
572.It Bq Er EINVAL
573An unknown socket option name was given.
574.It Bq Er EINVAL
575The IP option field was improperly formed;
576an option field was shorter than the minimum value
577or longer than the option buffer provided.
578.El
579.Pp
580The following errors may occur when attempting to send
581.Tn IP
582datagrams via a
583.Dq raw socket
584with the
585.Em IP_HDRINCL
586option set:
587.Bl -tag -width Er
588.It Bq Er EINVAL
589The user-supplied ip_len field was not equal to the length of the datagram
590written to the socket.
591.El
592.Sh SEE ALSO
593.Xr getsockopt 2 ,
594.Xr recv 2 ,
595.Xr send 2 ,
596.Xr byteorder 4 ,
597.Xr icmp 4 ,
598.Xr inet 4 ,
599.Xr intro 4
600.Sh HISTORY
601The
602.Nm
603protocol appeared in
604.Bx 4.2 .
605