xref: /freebsd/share/man/man4/ip.4 (revision 2546665afcaf0d53dc2c7058fee96354b3680f5a)
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.
330In scenarios such as benchmarking, this behavior may be undesirable.
331In these cases,
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.Va imr_interface
435should be set to
436.Dv INADDR_ANY
437to choose the default multicast interface,
438or the
439.Tn IP
440address of a particular multicast-capable interface if
441the host is multihomed.
442Since
443.Fx 4.4 ,
444if the
445.Va imr_interface
446member is within the network range
447.Li 0.0.0.0/8 ,
448it is treated as an interface index in the system interface MIB,
449as per the RIP Version 2 MIB Extension (RFC-1724).
450.Pp
451Membership is associated with a single interface;
452programs running on multihomed hosts may need to
453join the same group on more than one interface.
454Up to
455.Dv IP_MAX_MEMBERSHIPS
456(currently 20) memberships may be added on a
457single socket.
458.Pp
459To drop a membership, use:
460.Bd -literal
461struct ip_mreq mreq;
462setsockopt(s, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));
463.Ed
464.Pp
465where
466.Fa mreq
467contains the same values as used to add the membership.
468Memberships are dropped when the socket is closed or the process exits.
469.\"-----------------------
470.Ss "Raw IP Sockets"
471.Pp
472Raw
473.Tn IP
474sockets are connectionless,
475and are normally used with the
476.Xr sendto 2
477and
478.Xr recvfrom 2
479calls, though the
480.Xr connect 2
481call may also be used to fix the destination for future
482packets (in which case the
483.Xr read 2
484or
485.Xr recv 2
486and
487.Xr write 2
488or
489.Xr send 2
490system calls may be used).
491.Pp
492If
493.Fa proto
494is 0, the default protocol
495.Dv IPPROTO_RAW
496is used for outgoing
497packets, and only incoming packets destined for that protocol
498are received.
499If
500.Fa proto
501is non-zero, that protocol number will be used on outgoing packets
502and to filter incoming packets.
503.Pp
504Outgoing packets automatically have an
505.Tn IP
506header prepended to
507them (based on the destination address and the protocol
508number the socket is created with),
509unless the
510.Dv IP_HDRINCL
511option has been set.
512Incoming packets are received with
513.Tn IP
514header and options intact.
515.Pp
516.Dv IP_HDRINCL
517indicates the complete IP header is included with the data
518and may be used only with the
519.Dv SOCK_RAW
520type.
521.Bd -literal
522#include <netinet/in_systm.h>
523#include <netinet/ip.h>
524
525int hincl = 1;                  /* 1 = on, 0 = off */
526setsockopt(s, IPPROTO_IP, IP_HDRINCL, &hincl, sizeof(hincl));
527.Ed
528.Pp
529Unlike previous
530.Bx
531releases, the program must set all
532the fields of the IP header, including the following:
533.Bd -literal
534ip->ip_v = IPVERSION;
535ip->ip_hl = hlen >> 2;
536ip->ip_id = 0;  /* 0 means kernel set appropriate value */
537ip->ip_off = offset;
538.Ed
539.Pp
540The
541.Va ip_len
542and
543.Va ip_off
544fields
545.Em must
546be provided in host byte order .
547All other fields must be provided in network byte order.
548See
549.Xr byteorder 4
550for more information on network byte order.
551If the
552.Va ip_id
553field is set to 0 then the kernel will choose an
554appropriate value.
555If the header source address is set to
556.Dv INADDR_ANY ,
557the kernel will choose an appropriate address.
558.Sh ERRORS
559A socket operation may fail with one of the following errors returned:
560.Bl -tag -width Er
561.It Bq Er EISCONN
562when trying to establish a connection on a socket which
563already has one, or when trying to send a datagram with the destination
564address specified and the socket is already connected;
565.It Bq Er ENOTCONN
566when trying to send a datagram, but
567no destination address is specified, and the socket hasn't been
568connected;
569.It Bq Er ENOBUFS
570when the system runs out of memory for
571an internal data structure;
572.It Bq Er EADDRNOTAVAIL
573when an attempt is made to create a
574socket with a network address for which no network interface
575exists.
576.It Bq Er EACCES
577when an attempt is made to create
578a raw IP socket by a non-privileged process.
579.El
580.Pp
581The following errors specific to
582.Tn IP
583may occur when setting or getting
584.Tn IP
585options:
586.Bl -tag -width Er
587.It Bq Er EINVAL
588An unknown socket option name was given.
589.It Bq Er EINVAL
590The IP option field was improperly formed;
591an option field was shorter than the minimum value
592or longer than the option buffer provided.
593.El
594.Pp
595The following errors may occur when attempting to send
596.Tn IP
597datagrams via a
598.Dq raw socket
599with the
600.Dv IP_HDRINCL
601option set:
602.Bl -tag -width Er
603.It Bq Er EINVAL
604The user-supplied
605.Va ip_len
606field was not equal to the length of the datagram written to the socket.
607.El
608.Sh SEE ALSO
609.Xr getsockopt 2 ,
610.Xr recv 2 ,
611.Xr send 2 ,
612.Xr byteorder 4 ,
613.Xr icmp 4 ,
614.Xr inet 4 ,
615.Xr intro 4
616.Sh HISTORY
617The
618.Nm
619protocol appeared in
620.Bx 4.2 .
621