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