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