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