xref: /freebsd/share/man/man4/netintro.4 (revision 2008043f386721d58158e37e0d7e50df8095942d)
1.\" Copyright (c) 1983, 1990, 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.\"     @(#)netintro.4	8.2 (Berkeley) 11/30/93
29.\"
30.Dd October 14, 2020
31.Dt NETINTRO 4
32.Os
33.Sh NAME
34.Nm networking
35.Nd introduction to networking facilities
36.Sh SYNOPSIS
37.In sys/types.h
38.In sys/time.h
39.In sys/socket.h
40.In net/if.h
41.In net/route.h
42.Sh DESCRIPTION
43This section is a general introduction to the networking facilities
44available in the system.
45Documentation in this part of section
464 is broken up into three areas:
47.Em protocol families
48(domains),
49.Em protocols ,
50and
51.Em network interfaces .
52.Pp
53All network protocols are associated with a specific
54.Em protocol family .
55A protocol family provides basic services to the protocol
56implementation to allow it to function within a specific
57network environment.
58These services may include
59packet fragmentation and reassembly, routing, addressing, and
60basic transport.
61A protocol family may support multiple
62methods of addressing, though the current protocol implementations
63do not.
64A protocol family is normally comprised of a number of protocols, one per
65.Xr socket 2
66type.
67It is not required that a protocol family support all socket types.
68A protocol family may contain multiple
69protocols supporting the same socket abstraction.
70.Pp
71A protocol supports one of the socket abstractions detailed in
72.Xr socket 2 .
73A specific protocol may be accessed either by creating a
74socket of the appropriate type and protocol family, or
75by requesting the protocol explicitly when creating a socket.
76Protocols normally accept only one type of address format,
77usually determined by the addressing structure inherent in
78the design of the protocol family/network architecture.
79Certain semantics of the basic socket abstractions are
80protocol specific.
81All protocols are expected to support
82the basic model for their particular socket type, but may,
83in addition, provide non-standard facilities or extensions
84to a mechanism.
85For example, a protocol supporting the
86.Dv SOCK_STREAM
87abstraction may allow more than one byte of out-of-band
88data to be transmitted per out-of-band message.
89.Pp
90A network interface is similar to a device interface.
91Network interfaces comprise the lowest layer of the
92networking subsystem, interacting with the actual transport
93hardware.
94An interface may support one or more protocol families and/or address formats.
95The SYNOPSIS section of each network interface
96entry gives a sample specification
97of the related drivers for use in providing
98a system description to the
99.Xr config 8
100program.
101The DIAGNOSTICS section lists messages which may appear on the console
102and/or in the system error log,
103.Pa /var/log/messages
104(see
105.Xr syslogd 8 ) ,
106due to errors in device operation.
107.Sh PROTOCOLS
108The system currently supports the
109Internet
110protocols, the Xerox Network Systems(tm) protocols,
111and some of the
112.Tn ISO OSI
113protocols.
114Raw socket interfaces are provided to the
115.Tn IP
116protocol
117layer of the
118Internet, and to the
119.Tn IDP
120protocol of Xerox
121.Tn NS .
122Consult the appropriate manual pages in this section for more
123information regarding the support for each protocol family.
124.Sh ADDRESSING
125Associated with each protocol family is an address
126format.
127All network addresses adhere to a general structure,
128called a sockaddr, described below.
129However, each protocol
130imposes finer and more specific structure, generally renaming
131the variant, which is discussed in the protocol family manual
132page alluded to above.
133.Bd -literal -offset indent
134struct sockaddr {
135    u_char	sa_len;
136    u_char	sa_family;
137    char	sa_data[14];
138};
139.Ed
140.Pp
141The field
142.Va sa_len
143contains the total length of the structure,
144which may exceed 16 bytes.
145The following address values for
146.Va sa_family
147are known to the system
148(and additional formats are defined for possible future implementation):
149.Bd -literal
150#define    AF_UNIX      1    /* local to host (pipes, portals) */
151#define    AF_INET      2    /* internetwork: UDP, TCP, etc. */
152#define    AF_NS        6    /* Xerox NS protocols */
153#define    AF_CCITT     10   /* CCITT protocols, X.25 etc */
154#define    AF_HYLINK    15   /* NSC Hyperchannel */
155#define    AF_ISO       18   /* ISO protocols */
156.Ed
157.Sh ROUTING
158.Fx
159provides some packet routing facilities.
160The kernel maintains a routing information database, which
161is used in selecting the appropriate network interface when
162transmitting packets.
163.Pp
164A user process (or possibly multiple co-operating processes)
165maintains this database by sending messages over a special kind
166of socket.
167This supplants fixed size
168.Xr ioctl 2
169used in earlier releases.
170.Pp
171This facility is described in
172.Xr route 4 .
173.Sh INTERFACES
174Each network interface in a system corresponds to a
175path through which messages may be sent and received.
176A network interface usually has a hardware device associated with it, though
177certain interfaces such as the loopback interface,
178.Xr lo 4 ,
179do not.
180.Pp
181The following
182.Xr ioctl 2
183calls may be used to manipulate network interfaces.
184The
185.Fn ioctl
186is made on a socket (typically of type
187.Dv SOCK_DGRAM )
188in the desired domain.
189Most of the requests supported in earlier releases
190take an
191.Vt ifreq
192structure as its parameter.
193This structure has the form
194.Bd -literal
195struct	ifreq {
196#define    IFNAMSIZ    16
197    char    ifr_name[IFNAMSIZ];        /* if name, e.g. "en0" */
198    union {
199        struct    sockaddr ifru_addr;
200        struct    sockaddr ifru_dstaddr;
201        struct    sockaddr ifru_broadaddr;
202        struct    ifreq_buffer ifru_buffer;
203        short     ifru_flags[2];
204        short     ifru_index;
205        int       ifru_metric;
206        int       ifru_mtu;
207        int       ifru_phys;
208        int       ifru_media;
209        caddr_t   ifru_data;
210        int       ifru_cap[2];
211    } ifr_ifru;
212#define ifr_addr      ifr_ifru.ifru_addr      /* address */
213#define ifr_dstaddr   ifr_ifru.ifru_dstaddr   /* other end of p-to-p link */
214#define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */
215#define ifr_buffer    ifr_ifru.ifru_buffer    /* user supplied buffer with its length */
216#define ifr_flags     ifr_ifru.ifru_flags[0]  /* flags (low 16 bits) */
217#define ifr_flagshigh ifr_ifru.ifru_flags[1]  /* flags (high 16 bits) */
218#define ifr_metric    ifr_ifru.ifru_metric    /* metric */
219#define ifr_mtu       ifr_ifru.ifru_mtu       /* mtu */
220#define ifr_phys      ifr_ifru.ifru_phys      /* physical wire */
221#define ifr_media     ifr_ifru.ifru_media     /* physical media */
222#define ifr_data      ifr_ifru.ifru_data      /* for use by interface */
223#define ifr_reqcap    ifr_ifru.ifru_cap[0]    /* requested capabilities */
224#define ifr_curcap    ifr_ifru.ifru_cap[1]    /* current capabilities */
225#define ifr_index     ifr_ifru.ifru_index     /* interface index */
226};
227.Ed
228.Pp
229.Fn Ioctl
230requests to obtain addresses and requests both to set and
231retrieve other data are still fully supported
232and use the
233.Vt ifreq
234structure:
235.Bl -tag -width SIOCGIFBRDADDR
236.It Dv SIOCGIFADDR
237Get interface address for protocol family.
238.It Dv SIOCGIFDSTADDR
239Get point to point address for protocol family and interface.
240.It Dv SIOCGIFBRDADDR
241Get broadcast address for protocol family and interface.
242.It Dv SIOCSIFCAP
243Attempt to set the enabled capabilities field for the interface
244to the value of the
245.Va ifr_reqcap
246field of the
247.Vt ifreq
248structure.
249Note that, depending on the particular interface features,
250some capabilities may appear hard-coded to enabled, or toggling
251a capability may affect the status of other ones.
252The supported capabilities field is read-only, and the
253.Va ifr_curcap
254field is unused by this call.
255.It Dv SIOCGIFCAP
256Get the interface capabilities fields.
257The values for supported and enabled capabilities will be returned in the
258.Va ifr_reqcap
259and
260.Va ifr_curcap
261fields of the
262.Vt ifreq
263structure, respectively.
264.It Dv SIOCGIFDESCR
265Get the interface description, returned in the
266.Va buffer
267field of
268.Va ifru_buffer
269struct.
270The user supplied buffer length should be defined in the
271.Va length
272field of
273.Va ifru_buffer
274struct passed in as parameter, and the length would include
275the terminating nul character.
276If there is not enough space to hold the interface length,
277no copy would be done and the
278.Va buffer
279field of
280.Va ifru_buffer
281would be set to NULL.
282The kernel will store the buffer length in the
283.Va length
284field upon return, regardless whether the buffer itself is
285sufficient to hold the data.
286.It Dv SIOCSIFDESCR
287Set the interface description to the value of the
288.Va buffer
289field of
290.Va ifru_buffer
291struct, with
292.Va length
293field specifying its length (counting the terminating nul).
294.It Dv SIOCSIFFLAGS
295Set interface flags field.
296If the interface is marked down,
297any processes currently routing packets through the interface
298are notified;
299some interfaces may be reset so that incoming packets are no longer received.
300When marked up again, the interface is reinitialized.
301.It Dv SIOCGIFFLAGS
302Get interface flags.
303.It Dv SIOCSIFMETRIC
304Set interface routing metric.
305The metric is used only by user-level routers.
306.It Dv SIOCGIFMETRIC
307Get interface metric.
308.It Dv SIOCIFCREATE
309Attempt to create the specified interface.
310If the interface name is given without a unit number the system
311will attempt to create a new interface with an arbitrary unit number.
312On successful return the
313.Va ifr_name
314field will contain the new interface name.
315.It Dv SIOCIFDESTROY
316Attempt to destroy the specified interface.
317.El
318.Pp
319There are two requests that make use of a new structure:
320.Bl -tag -width SIOCGIFBRDADDR
321.It Dv SIOCAIFADDR
322An interface may have more than one address associated with it
323in some protocols.
324This request provides a means to
325add additional addresses (or modify characteristics of the
326primary address if the default address for the address family
327is specified).
328Rather than making separate calls to
329set destination or broadcast addresses, or network masks
330(now an integral feature of multiple protocols)
331a separate structure is used to specify all three facets simultaneously
332(see below).
333One would use a slightly tailored version of this struct specific
334to each family (replacing each sockaddr by one
335of the family-specific type).
336Where the sockaddr itself is larger than the
337default size, one needs to modify the
338.Fn ioctl
339identifier itself to include the total size, as described in
340.Fn ioctl .
341.It Dv SIOCDIFADDR
342This requests deletes the specified address from the list
343associated with an interface.
344It also uses the
345.Vt ifaliasreq
346structure to allow for the possibility of protocols allowing
347multiple masks or destination addresses, and also adopts the
348convention that specification of the default address means
349to delete the first address for the interface belonging to
350the address family in which the original socket was opened.
351.It Dv SIOCGIFALIAS
352This request provides means to get additional addresses
353together with netmask and broadcast/destination from an
354interface.
355It also uses the
356.Vt ifaliasreq
357structure.
358.It Dv SIOCGIFCONF
359Get interface configuration list.
360This request takes an
361.Vt ifconf
362structure (see below) as a value-result parameter.
363The
364.Va ifc_len
365field should be initially set to the size of the buffer
366pointed to by
367.Va ifc_buf .
368On return it will contain the length, in bytes, of the
369configuration list.
370.It Dv SIOCIFGCLONERS
371Get list of clonable interfaces.
372This request takes an
373.Vt if_clonereq
374structure (see below) as a value-result parameter.
375The
376.Va ifcr_count
377field should be set to the number of
378.Dv IFNAMSIZ
379sized strings that can be fit in the buffer pointed to by
380.Va ifcr_buffer .
381On return,
382.Va ifcr_total
383will be set to the number of clonable interfaces and the buffer pointed
384to by
385.Va ifcr_buffer
386will be filled with the names of clonable interfaces aligned on
387.Dv IFNAMSIZ
388boundaries.
389.El
390.Bd -literal
391/*
392* Structure used in SIOCAIFADDR request.
393*/
394struct ifaliasreq {
395        char    ifra_name[IFNAMSIZ];   /* if name, e.g. "en0" */
396        struct  sockaddr        ifra_addr;
397        struct  sockaddr        ifra_broadaddr;
398        struct  sockaddr        ifra_mask;
399};
400.Ed
401.Bd -literal
402/*
403* Structure used in SIOCGIFCONF request.
404* Used to retrieve interface configuration
405* for machine (useful for programs which
406* must know all networks accessible).
407*/
408struct ifconf {
409    int   ifc_len;		/* size of associated buffer */
410    union {
411        caddr_t    ifcu_buf;
412        struct     ifreq *ifcu_req;
413    } ifc_ifcu;
414#define ifc_buf ifc_ifcu.ifcu_buf /* buffer address */
415#define ifc_req ifc_ifcu.ifcu_req /* array of structures returned */
416};
417.Ed
418.Bd -literal
419/* Structure used in SIOCIFGCLONERS request. */
420struct if_clonereq {
421        int     ifcr_total;     /* total cloners (out) */
422        int     ifcr_count;     /* room for this many in user buffer */
423        char    *ifcr_buffer;   /* buffer for cloner names */
424};
425.Ed
426.Bd -literal
427/* Structure used in SIOCGIFDESCR and SIOCSIFDESCR requests */
428struct ifreq_buffer {
429        size_t  length;         /* length of the buffer */
430        void   *buffer;         /* pointer to userland space buffer */
431};
432.Ed
433.Sh SEE ALSO
434.Xr ioctl 2 ,
435.Xr socket 2 ,
436.Xr intro 4 ,
437.Xr config 8 ,
438.Xr routed 8 ,
439.Xr ifnet 9
440.Sh HISTORY
441The
442.Nm netintro
443manual appeared in
444.Bx 4.3 tahoe .
445