intro(4N) 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: protocol-families,
protocols, and network interfaces. Entries describing a
protocol-family are marked ``4F'', while entries describing
protocol use are marked ``4P''. Devices for network inter-
faces are marked ``7C''.
All network protocols are associated with a specific
protocol-family. 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 sup-
port multiple methods of addressing, though the current pro-
tocol implementations do not. A protocol-family is normally
comprised of a number of protocols, one per socket(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 socket(2). A specific protocol may be accessed either by
creating a socket of the appropriate type and protocol-
family, or by requesting the protocol explicitly when creat-
ing 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 net-
work interface entry gives a sample specification of the
Page 1 CX/UX Networking
intro(4N) intro(4N)
related drivers for use in providing a system description to
the config(1M) program. The DIAGNOSTICS section lists mes-
sages which may appear on the console and in the system
error log /usr/adm/messages due to errors in device opera-
tion.
PROTOCOLS
The system currently supports only the DARPA Internet proto-
cols fully. Raw socket interfaces are provided to IP proto-
col layer of the DARPA Internet, to the IMP link layer
(1822), and to Xerox PUP-1 layer operating on top of 3Mb/s
Ethernet interfaces. 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:
#define AFUNIX 1 /* local to host (pipes, portals) */
#define AFINET 2 /* internetwork: UDP, TCP, etc. */
#define AFIMPLINK 3 /* arpanet imp addresses */
#define AFPUP 4 /* pup protocols: e.g. BSP */
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 ioctl(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
< net/route.h >;
struct rtentry {
ulong rthash; /* to speed lookups */
struct sockaddr rtdst; /* key */
struct sockaddr rtgateway; /* value */
short rtflags; /* up/down?, host/net */
short rtrefcnt; /* # held references */
ulong rtuse; /* raw # packets forwarded */
struct ifnet *rtifp; /* the answer: interface to use */
lockt rtlock; /* protects rtrefcnt and rtuse */
};
with rt_flags defined from,
Page 2 CX/UX Networking
intro(4N) intro(4N)
#define RTFUP 0x1 /* route usable */
#define RTFGATEWAY 0x2 /* destination is a gateway */
#define RTFHOST 0x4 /* host entry (net otherwise) */
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, each network inter-
face autoconfigured installs a routing table entry when it
wishes to have packets sent through it. Normally the inter-
face specifies the route through it is a ``direct'' connec-
tion 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 may be requested to
address the packet to an entity different from the eventual
recipient (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 (rt_refcnt is non-zero), the
resources associated with it will not be reclaimed until
further references to it are released.
The routing code returns EEXIST if requested to duplicate an
existing entry, ESRCH if requested to delete a non-existant
entry, or ENOBUFS if insufficient resources were available
to install a new route.
User processes read the routing tables through the /dev/kmem
device.
The rt_use field contains the number of packets sent along
the route. This value is used to select among multiple
routes to the same destination. When multiple routes to the
same destination exist, the least used route is selected.
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.
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,
lo(7C), do not.
Page 3 CX/UX Networking
intro(4N) intro(4N)
At boot time each interface which has underlying hardware
support makes itself known to the system during the autocon-
figuration process. Once the interface has acquired its
address it is expected to install a routing table entry so
that messages may be routed through it. Most interfaces
require some part of their address specified with an SIOCSI-
FADDR ioctl before they will allow traffic to flow through
them. On interfaces where the network-link layer address
mapping is static, only the network number is taken from the
ioctl; the remainder is found in a hardware specific manner.
On interfaces which provide dynamic network-link layer
address mapping facilities (e.g. 10Mb/s Ethernets), the
entire address specified in the ioctl is used.
The following ioctl calls may be used to manipulate network
interfaces. Unless specified otherwise, the request takes
an ifrequest structure as its parameter. This structure has
the form
struct ifreq {
char ifrname[16]; /* name of interface (e.g. "ec0") */
union {
struct sockaddr ifruaddr;
struct sockaddr ifrudstaddr;
struct sockaddr ifrubroadaddr;
short ifruflags;
int ifrumetric;
caddrt ifrudata;
} ifrifru;
#define ifraddr ifrifru.ifruaddr /* address */
#define ifrdstaddr ifrifru.ifrudstaddr /* other end of p-to-p link */
#define ifrbroadaddr ifrifru.ifrubroadaddr /* broadcast address */
#define ifrflags ifrifru.ifruflags /* flags */
#define ifrmetric ifrifru.ifrumetric /* metric */
#define ifrdata ifrifru.ifrudata /* for use by the interface */
};
NOTE: In order to comply with the Object Compatibility
Standard (OCS) Networking Supplement, the ifru_oname[ ]
member of the ifr_ifru union shown above was removed. To
provide backwards support for any applications which may
have referenced this field, a renamed copy of the original
ifreq structure will exist in <net/if.h>. The renamed copy
can be referenced as __oifreq.
SIOCSIFADDR
Set interface address. Following the address assign-
ment, the ``initialization'' routine for the interface
is called.
SIOCGIFADDR
Get interface address.
Page 4 CX/UX Networking
intro(4N) intro(4N)
SIOCSIFDSTADDR
Set point to point address for interface.
SIOCGIFDSTADDR
Get point to point address for interface.
SIOCSIFFLAGS
Set interface flags field. If the interface is marked
down, any processes currently routing packets through
the interface are notified.
SIOCGIFFLAGS
Get interface flags.
SIOCGIFCONF
Get interface configuration list. This request takes
an ifconf structure (see below) as a value-result
parameter. The ifc_len field should be initially set
to the size of the buffer pointed to by ifc_buf. 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 ifclen; /* size of associated buffer */
union {
caddrt ifcubuf;
struct ifreq *ifcureq;
} ifcifcu;
#define ifcbuf ifcifcu.ifcubuf /* buffer address */
#define ifcreq ifcifcu.ifcureq /* array of structures returned */
};
SEE ALSO
socket(2), ioctl(2), intro(4), config(1M), routed(1M),
sockio(7)
Page 5 CX/UX Networking