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