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