4.3BSD-UWisc/man/cat4/intro.4n
INTRO(4N) UNIX Programmer's Manual INTRO(4N)
NAME
networking - introduction to networking facilities
SYNOPSIS
#include <sys/socket.h>
#include <net/route.h>
#include <net/if.h>
DESCRIPTION
This section briefly describes the networking facilities
available in the system. Documentation in this part of sec-
tion 4 is broken up into three areas: _p_r_o_t_o_c_o_l _f_a_m_i_l_i_e_s
(domains), _p_r_o_t_o_c_o_l_s, and _n_e_t_w_o_r_k _i_n_t_e_r_f_a_c_e_s. Entries
describing a protocol family are marked ``4F,'' while
entries describing protocol use are marked ``4P.'' Hardware
support for network interfaces are found among the standard
``4'' entries.
All network protocols are associated with a specific _p_r_o_t_o_-
_c_o_l _f_a_m_i_l_y. A protocol family provides basic services to
the protocol implementation to allow it to function within a
specific network environment. These services may include
packet fragmentation and reassembly, routing, addressing,
and basic transport. A protocol family may support multiple
methods of addressing, though the current protocol implemen-
tations do not. A protocol family is normally comprised of
a number of protocols, one per _s_o_c_k_e_t(2) type. It is not
required that a protocol family support all socket types. A
protocol family may contain multiple protocols supporting
the same socket abstraction.
A protocol supports one of the socket abstractions detailed
in _s_o_c_k_e_t(2). A specific protocol may be accessed either by
creating a socket of the appropriate type and protocol fam-
ily, or by requesting the protocol explicitly when creating
a socket. Protocols normally accept only one type of
address format, usually determined by the addressing struc-
ture inherent in the design of the protocol family/network
architecture. Certain semantics of the basic socket
abstractions are protocol specific. All protocols are
expected to support the basic model for their particular
socket type, but may, in addition, provide non-standard
facilities or extensions to a mechanism. For example, a
protocol supporting the SOCK_STREAM abstraction may allow
more than one byte of out-of-band data to be transmitted per
out-of-band message.
A network interface is similar to a device interface. Net-
work interfaces comprise the lowest layer of the networking
subsystem, interacting with the actual transport hardware.
An interface may support one or more protocol families
and/or address formats. The SYNOPSIS section of each
Printed 12/27/86 June 1, 1986 1
INTRO(4N) UNIX Programmer's Manual INTRO(4N)
network interface entry gives a sample specification of the
related drivers for use in providing a system description to
the _c_o_n_f_i_g(8) program. The DIAGNOSTICS section lists mes-
sages which may appear on the console and/or in the system
error log, /_u_s_r/_a_d_m/_m_e_s_s_a_g_e_s (see _s_y_s_l_o_g_d(8)), due to errors
in device operation.
PROTOCOLS
The system currently supports the DARPA Internet protocols
and the Xerox Network Systems(tm) protocols. Raw socket
interfaces are provided to the IP protocol layer of the
DARPA Internet, to the IMP link layer (1822), and to the IDP
protocol of Xerox NS. Consult the appropriate manual pages
in this section for more information regarding the support
for each protocol family.
ADDRESSING
Associated with each protocol family is an address format.
The following address formats are used by the system (and
additional formats are defined for possible future implemen-
tation):
#define AF_UNIX 1 /* local to host (pipes, portals) */
#define AF_INET 2 /* internetwork: UDP, TCP, etc. */
#define AF_IMPLINK 3 /* arpanet imp addresses */
#define AF_PUP 4 /* pup protocols: e.g. BSP */
#define AF_NS 6 /* Xerox NS protocols */
#define AF_HYLINK 15 /* NSC Hyperchannel */
ROUTING
The network facilities provided limited packet routing. A
simple set of data structures comprise a ``routing table''
used in selecting the appropriate network interface when
transmitting packets. This table contains a single entry
for each route to a specific network or host. A user pro-
cess, the routing daemon, maintains this data base with the
aid of two socket-specific _i_o_c_t_l(2) commands, SIOCADDRT and
SIOCDELRT. The commands allow the addition and deletion of
a single routing table entry, respectively. Routing table
manipulations may only be carried out by super-user.
A routing table entry has the following form, as defined in
<_n_e_t/_r_o_u_t_e._h>;
struct rtentry {
u_long rt_hash;
struct sockaddr rt_dst;
struct sockaddr rt_gateway;
short rt_flags;
short rt_refcnt;
u_long rt_use;
struct ifnet *rt_ifp;
Printed 12/27/86 June 1, 1986 2
INTRO(4N) UNIX Programmer's Manual INTRO(4N)
};
with _r_t__f_l_a_g_s defined from,
#define RTF_UP 0x1 /* route usable */
#define RTF_GATEWAY 0x2 /* destination is a gateway */
#define RTF_HOST 0x4 /* host entry (net otherwise) */
#define RTF_DYNAMIC 0x10 /* created dynamically (by redirect) */
Routing table entries come in three flavors: for a specific
host, for all hosts on a specific network, for any destina-
tion not matched by entries of the first two types (a wild-
card route). When the system is booted and addresses are
assigned to the network interfaces, each protocol family
installs a routing table entry for each interface when it is
ready for traffic. Normally the protocol specifies the
route through each interface as a ``direct'' connection to
the destination host or network. If the route is direct,
the transport layer of a protocol family usually requests
the packet be sent to the same host specified in the packet.
Otherwise, the interface is requested to address the packet
to the gateway listed in the routing entry (i.e. the packet
is forwarded).
Routing table entries installed by a user process may not
specify the hash, reference count, use, or interface fields;
these are filled in by the routing routines. If a route is
in use when it is deleted (_r_t__r_e_f_c_n_t is non-zero), the rout-
ing entry will be marked down and removed from the routing
table, but the resources associated with it will not be
reclaimed until all references to it are released. The rout-
ing code returns EEXIST if requested to duplicate an exist-
ing entry, ESRCH if requested to delete a non-existent
entry, or ENOBUFS if insufficient resources were available
to install a new route. User processes read the routing
tables through the /_d_e_v/_k_m_e_m device. The _r_t__u_s_e field con-
tains the number of packets sent along the route.
When routing a packet, the kernel will first attempt to find
a route to the destination host. Failing that, a search is
made for a route to the network of the destination.
Finally, any route to a default (``wildcard'') gateway is
chosen. If multiple routes are present in the table, the
first route found will be used. If no entry is found, the
destination is declared to be unreachable.
A wildcard routing entry is specified with a zero destina-
tion address value. Wildcard routes are used only when the
system fails to find a route to the destination host and
network. The combination of wildcard routes and routing
redirects can provide an economical mechanism for routing
traffic.
Printed 12/27/86 June 1, 1986 3
INTRO(4N) UNIX Programmer's Manual INTRO(4N)
INTERFACES
Each network interface in a system corresponds to a path
through which messages may be sent and received. A network
interface usually has a hardware device associated with it,
though certain interfaces such as the loopback interface,
_l_o(4), do not.
The following _i_o_c_t_l calls may be used to manipulate network
interfaces. The _i_o_c_t_l is made on a socket (typically of
type SOCK_DGRAM) in the desired domain. Unless specified
otherwise, the request takes an _i_f_r_e_q_u_e_s_t structure as its
parameter. This structure has the form
struct ifreq {
char ifr_name[16]; /* name of interface (e.g. "ec0") */
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
short ifru_flags;
int ifru_metric;
} ifr_ifru;
#define ifr_addr ifr_ifru.ifru_addr /* address */
#define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */
#define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */
#define ifr_flags ifr_ifru.ifru_flags /* flags */
#define ifr_metric ifr_ifru.ifru_metric /* routing metric */
};
SIOCSIFADDR
Set interface address for protocol family. Following
the address assignment, the ``initialization'' routine
for the interface is called.
SIOCGIFADDR
Get interface address for protocol family.
SIOCSIFDSTADDR
Set point to point address for protocol family and
interface.
SIOCGIFDSTADDR
Get point to point address for protocol family and
interface.
SIOCSIFBRDADDR
Set broadcast address for protocol family and inter-
face.
SIOCGIFBRDADDR
Get broadcast address for protocol family and inter-
face.
Printed 12/27/86 June 1, 1986 4
INTRO(4N) UNIX Programmer's Manual INTRO(4N)
SIOCSIFFLAGS
Set interface flags field. If the interface is marked
down, any processes currently routing packets through
the interface are notified; some interfaces may be
reset so that incoming packets are no longer received.
When marked up again, the interface is reinitialized.
SIOCGIFFLAGS
Get interface flags.
SIOCSIFMETRIC
Set interface routing metric. The metric is used only
by user-level routers.
SIOCGIFMETRIC
Get interface metric.
SIOCGIFCONF
Get interface configuration list. This request takes
an _i_f_c_o_n_f structure (see below) as a value-result
parameter. The _i_f_c__l_e_n field should be initially set
to the size of the buffer pointed to by _i_f_c__b_u_f. On
return it will contain the length, in bytes, of the
configuration list.
/*
* Structure used in SIOCGIFCONF request.
* Used to retrieve interface configuration
* for machine (useful for programs which
* must know all networks accessible).
*/
struct ifconf {
int ifc_len; /* size of associated buffer */
union {
caddr_t ifcu_buf;
struct ifreq *ifcu_req;
} ifc_ifcu;
#define ifc_buf ifc_ifcu.ifcu_buf /* buffer address */
#define ifc_req ifc_ifcu.ifcu_req /* array of structures returned */
};
SEE ALSO
socket(2), ioctl(2), intro(4), config(8), routed(8C)
Printed 12/27/86 June 1, 1986 5