xref: /freebsd/share/man/man4/inet.4 (revision b1f9167f94059fd55c630891d359bcff987bd7eb)
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.\"     From: @(#)inet.4	8.1 (Berkeley) 6/5/93
29.\" $FreeBSD$
30.\"
31.Dd January 26, 2012
32.Dt INET 4
33.Os
34.Sh NAME
35.Nm inet
36.Nd Internet protocol family
37.Sh SYNOPSIS
38.In sys/types.h
39.In netinet/in.h
40.Sh DESCRIPTION
41The Internet protocol family is a collection of protocols
42layered atop the
43.Em Internet Protocol
44.Pq Tn IP
45transport layer, and utilizing the Internet address format.
46The Internet family provides protocol support for the
47.Dv SOCK_STREAM , SOCK_DGRAM ,
48and
49.Dv SOCK_RAW
50socket types; the
51.Dv SOCK_RAW
52interface provides access to the
53.Tn IP
54protocol.
55.Sh ADDRESSING
56Internet addresses are four byte quantities, stored in
57network standard format (on little endian machines, such as the
58.Tn alpha ,
59.Tn amd64 ,
60.Tn i386
61and
62.Tn ia64
63these are word and byte reversed).
64The include file
65.In netinet/in.h
66defines this address
67as a discriminated union.
68.Pp
69Sockets bound to the Internet protocol family utilize
70the following addressing structure,
71.Bd -literal -offset indent
72struct sockaddr_in {
73	uint8_t		sin_len;
74	sa_family_t	sin_family;
75	in_port_t	sin_port;
76	struct in_addr	sin_addr;
77	char		sin_zero[8];
78};
79.Ed
80.Pp
81Sockets may be created with the local address
82.Dv INADDR_ANY
83to affect
84.Dq wildcard
85matching on incoming messages.
86The address in a
87.Xr connect 2
88or
89.Xr sendto 2
90call may be given as
91.Dv INADDR_ANY
92to mean
93.Dq this host .
94The distinguished address
95.Dv INADDR_BROADCAST
96is allowed as a shorthand for the broadcast address on the primary
97network if the first network configured supports broadcast.
98.Sh PROTOCOLS
99The Internet protocol family is comprised of
100the
101.Tn IP
102network protocol, Internet Control
103Message Protocol
104.Pq Tn ICMP ,
105Internet Group Management Protocol
106.Pq Tn IGMP ,
107Transmission Control
108Protocol
109.Pq Tn TCP ,
110and User Datagram Protocol
111.Pq Tn UDP .
112.Tn TCP
113is used to support the
114.Dv SOCK_STREAM
115abstraction while
116.Tn UDP
117is used to support the
118.Dv SOCK_DGRAM
119abstraction.
120A raw interface to
121.Tn IP
122is available
123by creating an Internet socket of type
124.Dv SOCK_RAW .
125The
126.Tn ICMP
127message protocol is accessible from a raw socket.
128.Pp
129The
130.Nm
131address on an interface consist of the address itself, the
132netmask, either broadcast address in case of a broadcast
133interface or peers address in case of point-to-point interface.
134The following
135.Xr ioctl 2
136commands are provided for a datagram socket in the Internet domain:
137.Pp
138.Bl -tag -width ".Dv SIOCGIFBRDADDR" -offset indent -compact
139.It Dv SIOCAIFADDR
140Add address to an interface.
141The command requires
142.Ft struct in_aliasreq
143as argument.
144.It Dv SIOCDIFADDR
145Delete address from an interface.
146The command requires
147.Ft struct ifreq
148as argument.
149.It Dv SIOCGIFADDR
150.It Dv SIOCGIFBRDADDR
151.It Dv SIOCGIFDSTADDR
152.It Dv SIOCGIFNETMASK
153Return address information from interface. The returned value
154is in
155.Ft struct ifreq .
156This way of address information retrieval is obsoleted, a
157preferred way is to use
158.Xr getifaddrs 3
159API.
160.El
161.Ss MIB Variables
162A number of variables are implemented in the net.inet branch of the
163.Xr sysctl 3
164MIB.
165In addition to the variables supported by the transport protocols
166(for which the respective manual pages may be consulted),
167the following general variables are defined:
168.Bl -tag -width IPCTL_FASTFORWARDING
169.It Dv IPCTL_FORWARDING
170.Pq ip.forwarding
171Boolean: enable/disable forwarding of IP packets.
172Defaults to off.
173.It Dv IPCTL_FASTFORWARDING
174.Pq ip.fastforwarding
175Boolean: enable/disable the use of
176.Tn fast IP forwarding
177code.
178Defaults to off.
179When
180.Tn fast IP forwarding
181is enabled, IP packets are forwarded directly to the appropriate network
182interface with direct processing to completion, which greatly improves
183the throughput.
184All packets for local IP addresses, non-unicast, or with IP options are
185handled by the normal IP input processing path.
186All features of the normal (slow) IP forwarding path are supported
187including firewall (through
188.Xr pfil 9
189hooks) checking, except
190.Xr ipsec 4
191tunnel brokering.
192The
193.Tn IP fastforwarding
194path does not generate ICMP redirect or source quench messages.
195.It Dv IPCTL_SENDREDIRECTS
196.Pq ip.redirect
197Boolean: enable/disable sending of ICMP redirects in response to
198.Tn IP
199packets for which a better, and for the sender directly reachable, route
200and next hop is known.
201Defaults to on.
202.It Dv IPCTL_DEFTTL
203.Pq ip.ttl
204Integer: default time-to-live
205.Pq Dq TTL
206to use for outgoing
207.Tn IP
208packets.
209.It Dv IPCTL_ACCEPTSOURCEROUTE
210.Pq ip.accept_sourceroute
211Boolean: enable/disable accepting of source-routed IP packets (default false).
212.It Dv IPCTL_SOURCEROUTE
213.Pq ip.sourceroute
214Boolean: enable/disable forwarding of source-routed IP packets (default false).
215.It Dv IPCTL_RTEXPIRE
216.Pq ip.rtexpire
217Integer: lifetime in seconds of protocol-cloned
218.Tn IP
219routes after the last reference drops (default one hour).
220This value varies dynamically as described above.
221.It Dv IPCTL_RTMINEXPIRE
222.Pq ip.rtminexpire
223Integer: minimum value of ip.rtexpire (default ten seconds).
224This value has no effect on user modifications, but restricts the dynamic
225adaptation described above.
226.It Dv IPCTL_RTMAXCACHE
227.Pq ip.rtmaxcache
228Integer: trigger level of cached, unreferenced, protocol-cloned routes
229which initiates dynamic adaptation (default 128).
230.It Va ip.process_options
231Integer: control IP options processing.
232By setting this variable to 0, all IP options in the incoming packets
233will be ignored, and the packets will be passed unmodified.
234By setting to 1, IP options in the incoming packets will be processed
235accordingly.
236By setting to 2, an
237.Tn ICMP
238.Dq "prohibited by filter"
239message will be sent back in response to incoming packets with IP options.
240Default is 1.
241This
242.Xr sysctl 8
243variable affects packets destined for a local host as well as packets
244forwarded to some other host.
245.It Va ip.random_id
246Boolean: control IP IDs generation behaviour.
247Setting this
248.Xr sysctl 8
249to non-zero causes the ID field in IP packets to be randomized instead of
250incremented by 1 with each packet generated.
251This closes a minor information leak which allows remote observers to
252determine the rate of packet generation on the machine by watching the
253counter.
254In the same time, on high-speed links, it can decrease the ID reuse
255cycle greatly.
256Default is 0 (sequential IP IDs).
257IPv6 flow IDs and fragment IDs are always random.
258.It Va ip.maxfragpackets
259Integer: maximum number of fragmented packets the host will accept and hold
260in the reassembling queue simultaneously.
2610 means that the host will not accept any fragmented packets.
262\-1 means that the host will accept as many fragmented packets as it receives.
263.It Va ip.maxfragsperpacket
264Integer: maximum number of fragments the host will accept and hold
265in the reassembling queue for a packet.
2660 means that the host will not accept any fragmented packets.
267.El
268.Sh SEE ALSO
269.Xr ioctl 2 ,
270.Xr socket 2 ,
271.Xr getifaddrs 3 ,
272.Xr sysctl 3 ,
273.Xr icmp 4 ,
274.Xr intro 4 ,
275.Xr ip 4 ,
276.Xr ipfirewall 4 ,
277.Xr route 4 ,
278.Xr tcp 4 ,
279.Xr udp 4 ,
280.Xr pfil 9
281.Rs
282.%T "An Introductory 4.3 BSD Interprocess Communication Tutorial"
283.%B PS1
284.%N 7
285.Re
286.Rs
287.%T "An Advanced 4.3 BSD Interprocess Communication Tutorial"
288.%B PS1
289.%N 8
290.Re
291.Sh HISTORY
292The
293.Nm
294protocol interface appeared in
295.Bx 4.2 .
296The
297.Dq protocol cloning
298code appeared in
299.Fx 2.1 .
300.Sh CAVEATS
301The Internet protocol support is subject to change as
302the Internet protocols develop.
303Users should not depend
304on details of the current implementation, but rather
305the services exported.
306