xref: /freebsd/share/man/man4/ip.4 (revision c243e4902be8df1e643c76b5f18b68bb77cc5268)
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 15, 2012
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
116.Dv IP_MINTTL
117may be used to set the minimum acceptable TTL a packet must have when
118received on a socket.
119All packets with a lower TTL are silently dropped.
120This option is only really useful when set to 255, preventing packets
121from outside the directly connected networks reaching local listeners
122on sockets.
123.Pp
124.Dv IP_DONTFRAG
125may be used to set the Don't Fragment flag on IP packets.
126Currently this option is respected only on
127.Xr udp 4
128and raw
129.Xr ip 4
130sockets, unless the
131.Dv IP_HDRINCL
132option has been set.
133On
134.Xr tcp 4
135sockets, the Don't Fragment flag is controlled by the Path
136MTU Discovery option.
137Sending a packet larger than the MTU size of the egress interface,
138determined by the destination address, returns an
139.Er EMSGSIZE
140error.
141.Pp
142If the
143.Dv IP_RECVDSTADDR
144option is enabled on a
145.Dv SOCK_DGRAM
146socket,
147the
148.Xr recvmsg 2
149call will return the destination
150.Tn IP
151address for a
152.Tn UDP
153datagram.
154The
155.Vt msg_control
156field in the
157.Vt msghdr
158structure points to a buffer
159that contains a
160.Vt cmsghdr
161structure followed by the
162.Tn IP
163address.
164The
165.Vt cmsghdr
166fields have the following values:
167.Bd -literal
168cmsg_len = CMSG_LEN(sizeof(struct in_addr))
169cmsg_level = IPPROTO_IP
170cmsg_type = IP_RECVDSTADDR
171.Ed
172.Pp
173The source address to be used for outgoing
174.Tn UDP
175datagrams on a socket that is not bound to a specific
176.Tn IP
177address can be specified as ancillary data with a type code of
178.Dv IP_SENDSRCADDR .
179The msg_control field in the msghdr structure should point to a buffer
180that contains a
181.Vt cmsghdr
182structure followed by the
183.Tn IP
184address.
185The cmsghdr fields should have the following values:
186.Bd -literal
187cmsg_len = CMSG_LEN(sizeof(struct in_addr))
188cmsg_level = IPPROTO_IP
189cmsg_type = IP_SENDSRCADDR
190.Ed
191.Pp
192For convenience,
193.Dv IP_SENDSRCADDR
194is defined to have the same value as
195.Dv IP_RECVDSTADDR ,
196so the
197.Dv IP_RECVDSTADDR
198control message from
199.Xr recvmsg 2
200can be used directly as a control message for
201.Xr sendmsg 2 .
202.\"
203.Pp
204If the
205.Dv IP_ONESBCAST
206option is enabled on a
207.Dv SOCK_DGRAM
208or a
209.Dv SOCK_RAW
210socket, the destination address of outgoing
211broadcast datagrams on that socket will be forced
212to the undirected broadcast address,
213.Dv INADDR_BROADCAST ,
214before transmission.
215This is in contrast to the default behavior of the
216system, which is to transmit undirected broadcasts
217via the first network interface with the
218.Dv IFF_BROADCAST
219flag set.
220.Pp
221This option allows applications to choose which
222interface is used to transmit an undirected broadcast
223datagram.
224For example, the following code would force an
225undirected broadcast to be transmitted via the interface
226configured with the broadcast address 192.168.2.255:
227.Bd -literal
228char msg[512];
229struct sockaddr_in sin;
230int onesbcast = 1;	/* 0 = disable (default), 1 = enable */
231
232setsockopt(s, IPPROTO_IP, IP_ONESBCAST, &onesbcast, sizeof(onesbcast));
233sin.sin_addr.s_addr = inet_addr("192.168.2.255");
234sin.sin_port = htons(1234);
235sendto(s, msg, sizeof(msg), 0, &sin, sizeof(sin));
236.Ed
237.Pp
238It is the application's responsibility to set the
239.Dv IP_TTL
240option
241to an appropriate value in order to prevent broadcast storms.
242The application must have sufficient credentials to set the
243.Dv SO_BROADCAST
244socket level option, otherwise the
245.Dv IP_ONESBCAST
246option has no effect.
247.Pp
248If the
249.Dv IP_BINDANY
250option is enabled on a
251.Dv SOCK_STREAM ,
252.Dv SOCK_DGRAM
253or a
254.Dv SOCK_RAW
255socket, one can
256.Xr bind 2
257to any address, even one not bound to any available network interface in the
258system.
259This functionality (in conjunction with special firewall rules) can be used for
260implementing a transparent proxy.
261The
262.Dv PRIV_NETINET_BINDANY
263privilege is needed to set this option.
264.Pp
265If the
266.Dv IP_RECVTTL
267option is enabled on a
268.Dv SOCK_DGRAM
269socket, the
270.Xr recvmsg 2
271call will return the
272.Tn IP
273.Tn TTL
274(time to live) field for a
275.Tn UDP
276datagram.
277The msg_control field in the msghdr structure points to a buffer
278that contains a cmsghdr structure followed by the
279.Tn TTL .
280The cmsghdr fields have the following values:
281.Bd -literal
282cmsg_len = CMSG_LEN(sizeof(u_char))
283cmsg_level = IPPROTO_IP
284cmsg_type = IP_RECVTTL
285.Ed
286.\"
287.Pp
288If the
289.Dv IP_RECVTOS
290option is enabled on a
291.Dv SOCK_DGRAM
292socket, the
293.Xr recvmsg 2
294call will return the
295.Tn IP
296.Tn TOS
297(type of service) field for a
298.Tn UDP
299datagram.
300The msg_control field in the msghdr structure points to a buffer
301that contains a cmsghdr structure followed by the
302.Tn TOS .
303The cmsghdr fields have the following values:
304.Bd -literal
305cmsg_len = CMSG_LEN(sizeof(u_char))
306cmsg_level = IPPROTO_IP
307cmsg_type = IP_RECVTOS
308.Ed
309.\"
310.Pp
311If the
312.Dv IP_RECVIF
313option is enabled on a
314.Dv SOCK_DGRAM
315socket, the
316.Xr recvmsg 2
317call returns a
318.Vt "struct sockaddr_dl"
319corresponding to the interface on which the
320packet was received.
321The
322.Va msg_control
323field in the
324.Vt msghdr
325structure points to a buffer that contains a
326.Vt cmsghdr
327structure followed by the
328.Vt "struct sockaddr_dl" .
329The
330.Vt cmsghdr
331fields have the following values:
332.Bd -literal
333cmsg_len = CMSG_LEN(sizeof(struct sockaddr_dl))
334cmsg_level = IPPROTO_IP
335cmsg_type = IP_RECVIF
336.Ed
337.Pp
338.Dv IP_PORTRANGE
339may be used to set the port range used for selecting a local port number
340on a socket with an unspecified (zero) port number.
341It has the following
342possible values:
343.Bl -tag -width IP_PORTRANGE_DEFAULT
344.It Dv IP_PORTRANGE_DEFAULT
345use the default range of values, normally
346.Dv IPPORT_HIFIRSTAUTO
347through
348.Dv IPPORT_HILASTAUTO .
349This is adjustable through the sysctl setting:
350.Va net.inet.ip.portrange.first
351and
352.Va net.inet.ip.portrange.last .
353.It Dv IP_PORTRANGE_HIGH
354use a high range of values, normally
355.Dv IPPORT_HIFIRSTAUTO
356and
357.Dv IPPORT_HILASTAUTO .
358This is adjustable through the sysctl setting:
359.Va net.inet.ip.portrange.hifirst
360and
361.Va net.inet.ip.portrange.hilast .
362.It Dv IP_PORTRANGE_LOW
363use a low range of ports, which are normally restricted to
364privileged processes on
365.Ux
366systems.
367The range is normally from
368.Dv IPPORT_RESERVED
369\- 1 down to
370.Li IPPORT_RESERVEDSTART
371in descending order.
372This is adjustable through the sysctl setting:
373.Va net.inet.ip.portrange.lowfirst
374and
375.Va net.inet.ip.portrange.lowlast .
376.El
377.Pp
378The range of privileged ports which only may be opened by
379root-owned processes may be modified by the
380.Va net.inet.ip.portrange.reservedlow
381and
382.Va net.inet.ip.portrange.reservedhigh
383sysctl settings.
384The values default to the traditional range,
3850 through
386.Dv IPPORT_RESERVED
387\- 1
388(0 through 1023), respectively.
389Note that these settings do not affect and are not accounted for in the
390use or calculation of the other
391.Va net.inet.ip.portrange
392values above.
393Changing these values departs from
394.Ux
395tradition and has security
396consequences that the administrator should carefully evaluate before
397modifying these settings.
398.Pp
399Ports are allocated at random within the specified port range in order
400to increase the difficulty of random spoofing attacks.
401In scenarios such as benchmarking, this behavior may be undesirable.
402In these cases,
403.Va net.inet.ip.portrange.randomized
404can be used to toggle randomization off.
405If more than
406.Va net.inet.ip.portrange.randomcps
407ports have been allocated in the last second, then return to sequential
408port allocation.
409Return to random allocation only once the current port allocation rate
410drops below
411.Va net.inet.ip.portrange.randomcps
412for at least
413.Va net.inet.ip.portrange.randomtime
414seconds.
415The default values for
416.Va net.inet.ip.portrange.randomcps
417and
418.Va net.inet.ip.portrange.randomtime
419are 10 port allocations per second and 45 seconds correspondingly.
420.Ss "Multicast Options"
421.Tn IP
422multicasting is supported only on
423.Dv AF_INET
424sockets of type
425.Dv SOCK_DGRAM
426and
427.Dv SOCK_RAW ,
428and only on networks where the interface
429driver supports multicasting.
430.Pp
431The
432.Dv IP_MULTICAST_TTL
433option changes the time-to-live (TTL)
434for outgoing multicast datagrams
435in order to control the scope of the multicasts:
436.Bd -literal
437u_char ttl;	/* range: 0 to 255, default = 1 */
438setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));
439.Ed
440.Pp
441Datagrams with a TTL of 1 are not forwarded beyond the local network.
442Multicast datagrams with a TTL of 0 will not be transmitted on any network,
443but may be delivered locally if the sending host belongs to the destination
444group and if multicast loopback has not been disabled on the sending socket
445(see below).
446Multicast datagrams with TTL greater than 1 may be forwarded
447to other networks if a multicast router is attached to the local network.
448.Pp
449For hosts with multiple interfaces, where an interface has not
450been specified for a multicast group membership,
451each multicast transmission is sent from the primary network interface.
452The
453.Dv IP_MULTICAST_IF
454option overrides the default for
455subsequent transmissions from a given socket:
456.Bd -literal
457struct in_addr addr;
458setsockopt(s, IPPROTO_IP, IP_MULTICAST_IF, &addr, sizeof(addr));
459.Ed
460.Pp
461where "addr" is the local
462.Tn IP
463address of the desired interface or
464.Dv INADDR_ANY
465to specify the default interface.
466.Pp
467To specify an interface by index, an instance of
468.Vt ip_mreqn
469may be passed instead.
470The
471.Vt imr_ifindex
472member should be set to the index of the desired interface,
473or 0 to specify the default interface.
474The kernel differentiates between these two structures by their size.
475.Pp
476The use of
477.Vt IP_MULTICAST_IF
478is
479.Em not recommended ,
480as multicast memberships are scoped to each
481individual interface.
482It is supported for legacy use only by applications,
483such as routing daemons, which expect to
484be able to transmit link-local IPv4 multicast datagrams (224.0.0.0/24)
485on multiple interfaces,
486without requesting an individual membership for each interface.
487.Pp
488.\"
489An interface's local IP address and multicast capability can
490be obtained via the
491.Dv SIOCGIFCONF
492and
493.Dv SIOCGIFFLAGS
494ioctls.
495Normal applications should not need to use this option.
496.Pp
497If a multicast datagram is sent to a group to which the sending host itself
498belongs (on the outgoing interface), a copy of the datagram is, by default,
499looped back by the IP layer for local delivery.
500The
501.Dv IP_MULTICAST_LOOP
502option gives the sender explicit control
503over whether or not subsequent datagrams are looped back:
504.Bd -literal
505u_char loop;	/* 0 = disable, 1 = enable (default) */
506setsockopt(s, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop));
507.Ed
508.Pp
509This option
510improves performance for applications that may have no more than one
511instance on a single host (such as a routing daemon), by eliminating
512the overhead of receiving their own transmissions.
513It should generally not
514be used by applications for which there may be more than one instance on a
515single host (such as a conferencing program) or for which the sender does
516not belong to the destination group (such as a time querying program).
517.Pp
518The sysctl setting
519.Va net.inet.ip.mcast.loop
520controls the default setting of the
521.Dv IP_MULTICAST_LOOP
522socket option for new sockets.
523.Pp
524A multicast datagram sent with an initial TTL greater than 1 may be delivered
525to the sending host on a different interface from that on which it was sent,
526if the host belongs to the destination group on that other interface.
527The loopback control option has no effect on such delivery.
528.Pp
529A host must become a member of a multicast group before it can receive
530datagrams sent to the group.
531To join a multicast group, use the
532.Dv IP_ADD_MEMBERSHIP
533option:
534.Bd -literal
535struct ip_mreq mreq;
536setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));
537.Ed
538.Pp
539where
540.Fa mreq
541is the following structure:
542.Bd -literal
543struct ip_mreq {
544    struct in_addr imr_multiaddr; /* IP multicast address of group */
545    struct in_addr imr_interface; /* local IP address of interface */
546}
547.Ed
548.Pp
549.Va imr_interface
550should be set to the
551.Tn IP
552address of a particular multicast-capable interface if
553the host is multihomed.
554It may be set to
555.Dv INADDR_ANY
556to choose the default interface, although this is not recommended;
557this is considered to be the first interface corresponding
558to the default route.
559Otherwise, the first multicast-capable interface
560configured in the system will be used.
561.Pp
562Prior to
563.Fx 7.0 ,
564if the
565.Va imr_interface
566member is within the network range
567.Li 0.0.0.0/8 ,
568it is treated as an interface index in the system interface MIB,
569as per the RIP Version 2 MIB Extension (RFC-1724).
570In versions of
571.Fx
572since 7.0, this behavior is no longer supported.
573Developers should
574instead use the RFC 3678 multicast source filter APIs; in particular,
575.Dv MCAST_JOIN_GROUP .
576.Pp
577Up to
578.Dv IP_MAX_MEMBERSHIPS
579memberships may be added on a single socket.
580Membership is associated with a single interface;
581programs running on multihomed hosts may need to
582join the same group on more than one interface.
583.Pp
584To drop a membership, use:
585.Bd -literal
586struct ip_mreq mreq;
587setsockopt(s, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));
588.Ed
589.Pp
590where
591.Fa mreq
592contains the same values as used to add the membership.
593Memberships are dropped when the socket is closed or the process exits.
594.\" TODO: Update this piece when IPv4 source-address selection is implemented.
595.Pp
596The IGMP protocol uses the primary IP address of the interface
597as its identifier for group membership.
598This is the first IP address configured on the interface.
599If this address is removed or changed, the results are
600undefined, as the IGMP membership state will then be inconsistent.
601If multiple IP aliases are configured on the same interface,
602they will be ignored.
603.Pp
604This shortcoming was addressed in IPv6; MLDv2 requires
605that the unique link-local address for an interface is
606used to identify an MLDv2 listener.
607.Ss "Source-Specific Multicast Options"
608Since
609.Fx 8.0 ,
610the use of Source-Specific Multicast (SSM) is supported.
611These extensions require an IGMPv3 multicast router in order to
612make best use of them.
613If a legacy multicast router is present on the link,
614.Fx
615will simply downgrade to the version of IGMP spoken by the router,
616and the benefits of source filtering on the upstream link
617will not be present, although the kernel will continue to
618squelch transmissions from blocked sources.
619.Pp
620Each group membership on a socket now has a filter mode:
621.Bl -tag -width MCAST_EXCLUDE
622.It Dv MCAST_EXCLUDE
623Datagrams sent to this group are accepted,
624unless the source is in a list of blocked source addresses.
625.It Dv MCAST_INCLUDE
626Datagrams sent to this group are accepted
627only if the source is in a list of accepted source addresses.
628.El
629.Pp
630Groups joined using the legacy
631.Dv IP_ADD_MEMBERSHIP
632option are placed in exclusive-mode,
633and are able to request that certain sources are blocked or allowed.
634This is known as the
635.Em delta-based API .
636.Pp
637To block a multicast source on an existing group membership:
638.Bd -literal
639struct ip_mreq_source mreqs;
640setsockopt(s, IPPROTO_IP, IP_BLOCK_SOURCE, &mreqs, sizeof(mreqs));
641.Ed
642.Pp
643where
644.Fa mreqs
645is the following structure:
646.Bd -literal
647struct ip_mreq_source {
648    struct in_addr imr_multiaddr; /* IP multicast address of group */
649    struct in_addr imr_sourceaddr; /* IP address of source */
650    struct in_addr imr_interface; /* local IP address of interface */
651}
652.Ed
653.Va imr_sourceaddr
654should be set to the address of the source to be blocked.
655.Pp
656To unblock a multicast source on an existing group:
657.Bd -literal
658struct ip_mreq_source mreqs;
659setsockopt(s, IPPROTO_IP, IP_UNBLOCK_SOURCE, &mreqs, sizeof(mreqs));
660.Ed
661.Pp
662The
663.Dv IP_BLOCK_SOURCE
664and
665.Dv IP_UNBLOCK_SOURCE
666options are
667.Em not permitted
668for inclusive-mode group memberships.
669.Pp
670To join a multicast group in
671.Dv MCAST_INCLUDE
672mode with a single source,
673or add another source to an existing inclusive-mode membership:
674.Bd -literal
675struct ip_mreq_source mreqs;
676setsockopt(s, IPPROTO_IP, IP_ADD_SOURCE_MEMBERSHIP, &mreqs, sizeof(mreqs));
677.Ed
678.Pp
679To leave a single source from an existing group in inclusive mode:
680.Bd -literal
681struct ip_mreq_source mreqs;
682setsockopt(s, IPPROTO_IP, IP_DROP_SOURCE_MEMBERSHIP, &mreqs, sizeof(mreqs));
683.Ed
684If this is the last accepted source for the group, the membership
685will be dropped.
686.Pp
687The
688.Dv IP_ADD_SOURCE_MEMBERSHIP
689and
690.Dv IP_DROP_SOURCE_MEMBERSHIP
691options are
692.Em not accepted
693for exclusive-mode group memberships.
694However, both exclusive and inclusive mode memberships
695support the use of the
696.Em full-state API
697documented in RFC 3678.
698For management of source filter lists using this API,
699please refer to
700.Xr sourcefilter 3 .
701.Pp
702The sysctl settings
703.Va net.inet.ip.mcast.maxsocksrc
704and
705.Va net.inet.ip.mcast.maxgrpsrc
706are used to specify an upper limit on the number of per-socket and per-group
707source filter entries which the kernel may allocate.
708.\"-----------------------
709.Ss "Raw IP Sockets"
710Raw
711.Tn IP
712sockets are connectionless,
713and are normally used with the
714.Xr sendto 2
715and
716.Xr recvfrom 2
717calls, though the
718.Xr connect 2
719call may also be used to fix the destination for future
720packets (in which case the
721.Xr read 2
722or
723.Xr recv 2
724and
725.Xr write 2
726or
727.Xr send 2
728system calls may be used).
729.Pp
730If
731.Fa proto
732is 0, the default protocol
733.Dv IPPROTO_RAW
734is used for outgoing
735packets, and only incoming packets destined for that protocol
736are received.
737If
738.Fa proto
739is non-zero, that protocol number will be used on outgoing packets
740and to filter incoming packets.
741.Pp
742Outgoing packets automatically have an
743.Tn IP
744header prepended to
745them (based on the destination address and the protocol
746number the socket is created with),
747unless the
748.Dv IP_HDRINCL
749option has been set.
750Incoming packets are received with
751.Tn IP
752header and options intact.
753.Pp
754.Dv IP_HDRINCL
755indicates the complete IP header is included with the data
756and may be used only with the
757.Dv SOCK_RAW
758type.
759.Bd -literal
760#include <netinet/in_systm.h>
761#include <netinet/ip.h>
762
763int hincl = 1;                  /* 1 = on, 0 = off */
764setsockopt(s, IPPROTO_IP, IP_HDRINCL, &hincl, sizeof(hincl));
765.Ed
766.Pp
767Unlike previous
768.Bx
769releases, the program must set all
770the fields of the IP header, including the following:
771.Bd -literal
772ip->ip_v = IPVERSION;
773ip->ip_hl = hlen >> 2;
774ip->ip_id = 0;  /* 0 means kernel set appropriate value */
775ip->ip_off = offset;
776.Ed
777.Pp
778The
779.Va ip_len
780and
781.Va ip_off
782fields
783.Em must
784be provided in host byte order.
785All other fields must be provided in network byte order.
786See
787.Xr byteorder 3
788for more information on network byte order.
789If the
790.Va ip_id
791field is set to 0 then the kernel will choose an
792appropriate value.
793If the header source address is set to
794.Dv INADDR_ANY ,
795the kernel will choose an appropriate address.
796.Sh ERRORS
797A socket operation may fail with one of the following errors returned:
798.Bl -tag -width Er
799.It Bq Er EISCONN
800when trying to establish a connection on a socket which
801already has one, or when trying to send a datagram with the destination
802address specified and the socket is already connected;
803.It Bq Er ENOTCONN
804when trying to send a datagram, but
805no destination address is specified, and the socket has not been
806connected;
807.It Bq Er ENOBUFS
808when the system runs out of memory for
809an internal data structure;
810.It Bq Er EADDRNOTAVAIL
811when an attempt is made to create a
812socket with a network address for which no network interface
813exists.
814.It Bq Er EACCES
815when an attempt is made to create
816a raw IP socket by a non-privileged process.
817.El
818.Pp
819The following errors specific to
820.Tn IP
821may occur when setting or getting
822.Tn IP
823options:
824.Bl -tag -width Er
825.It Bq Er EINVAL
826An unknown socket option name was given.
827.It Bq Er EINVAL
828The IP option field was improperly formed;
829an option field was shorter than the minimum value
830or longer than the option buffer provided.
831.El
832.Pp
833The following errors may occur when attempting to send
834.Tn IP
835datagrams via a
836.Dq raw socket
837with the
838.Dv IP_HDRINCL
839option set:
840.Bl -tag -width Er
841.It Bq Er EINVAL
842The user-supplied
843.Va ip_len
844field was not equal to the length of the datagram written to the socket.
845.El
846.Sh SEE ALSO
847.Xr getsockopt 2 ,
848.Xr recv 2 ,
849.Xr send 2 ,
850.Xr byteorder 3 ,
851.Xr icmp 4 ,
852.Xr igmp 4 ,
853.Xr inet 4 ,
854.Xr intro 4 ,
855.Xr multicast 4 ,
856.Xr sourcefilter 3
857.Rs
858.%A D. Thaler
859.%A B. Fenner
860.%A B. Quinn
861.%T "Socket Interface Extensions for Multicast Source Filters"
862.%N RFC 3678
863.%D Jan 2004
864.Re
865.Sh HISTORY
866The
867.Nm
868protocol appeared in
869.Bx 4.2 .
870The
871.Vt ip_mreqn
872structure appeared in
873.Tn Linux 2.4 .
874.Sh BUGS
875Before
876.Fx 10.0
877packets received on raw IP sockets had the
878.Va ip_hl
879subtracted from the
880.Va ip_len
881field.
882