TABLE OF CONTENTS

This section is a general introduction to the networking facilities available in
the system. Documentation in this part of section 4 is broken up into three
areas: protocol families (domains),
protocols, and network interfaces.

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
support multiple methods of addressing, though the current protocol
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 creating
a socket. Protocols normally accept only one type of address format, usually
determined by the addressing structure 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. Network
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 network
interface entry gives a sample specification of the related drivers for use
in providing a system description to the
config(8) program. The
DIAGNOSTICS section lists messages
which may appear on the console and/or in the system error log,
/var/log/messages (see
syslogd(8)), due to errors
in device operation.

Network interfaces may be collected together into interface
groups. An interface group is a container that can be used generically when
referring to any interface related by some criteria. When an action is
performed on an interface group, such as packet filtering by the
pf(4) subsystem, the operation
will be applied to each member interface in the group, if supported by the
subsystem. The ifconfig(8)
utility can be used to view and assign membership of an interface to an
interface group with the group modifier.

The system currently supports the Internet protocols (IPv4 and IPv6), MPLS, and
a few others. Raw socket interfaces are provided to the IP protocol layer of
the Internet. Consult the appropriate manual pages in this section for more
information regarding the support for each protocol family.

Associated with each protocol family is an address format. All network addresses
adhere to a general structure, called a sockaddr,
described below. However, each protocol imposes a finer, more specific
structure, generally renaming the variant, which is discussed in the protocol
family manual page alluded to above.

The field sa_len contains the total length
of the structure, which may exceed 16 bytes. The following address values
for sa_family are known to the system (and additional
formats are defined for possible future implementation):

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(4), do not.

The following
ioctl(2) calls may be used to
manipulate network interfaces. The
ioctl(2) is made on a socket
(typically of type SOCK_DGRAM) in the desired
domain. Most of the requests take an ifreq structure
pointer as their parameter. This structure is as follows:

Set the interface flags. 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.

Set the interface routing priority. The interface routing priority
influences the resulting routing priority of new static routes added to
the kernel using the specified interface. The value is in the range of 0
to 16 with smaller numbers being better.

An interface may have more than one address associated with it in some
protocols. This request provides a means to add additional addresses (or
modify characteristics of the primary address if the default address for
the address family is specified).

Rather than making separate calls to set destination or
broadcast addresses, or network masks (now an integral feature of
multiple protocols), a separate structure,
ifaliasreq, is used to specify all three facets
simultaneously (see below). One would use a slightly tailored version of
this structure specific to each family (replacing each
sockaddr by one of the family-specific type). One
should always set the length of a sockaddr, as
described in ioctl(2).

This request deletes the specified address from the list associated with
an interface. It also uses the ifaliasreq structure
to allow for the possibility of protocols allowing multiple masks or
destination addresses, and also adopts the convention that specification
of the default address means to delete the first address for the interface
belonging to the address family in which the original socket was
opened.

Get the 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.

Alternately, if the ifc_len passed in is
set to 0, SIOCGIFCONF will set
ifc_len to the size that
ifc_buf needs to be to fit the entire
configuration list and will not fill in the other parameters. This is
useful for determining the exact size that ifc_buf
needs to be in advance. Note, however, that this is an extension that
not all operating systems support.

Get the list of clonable interfaces. This request takes an
if_clonereq structure pointer (see below) as a
value-result parameter. The ifcr_count field should
be set to the number of IFNAMSIZ-sized strings
that can fit in the buffer pointed to by
ifcr_buffer. On return,
ifcr_total will be set to the number of clonable
interfaces, and the buffer pointed to by ifcr_buffer
will be filled with the names of clonable interfaces aligned on
IFNAMSIZ boundaries.

Retrieve the list of groups for which an interface is a member. The
interface is named by ifgr_name. On enter, the
amount of memory in which the group names will be written is stored in
ifgr_len, and the group names themselves will be
written to the memory pointed to by ifgr_groups. On
return, the amount of memory actually written is returned in
ifgr_len.

Alternately, if the ifgr_len passed in
is set to 0, SIOCGIFGROUP will set
ifgr_len to the size that
ifgr_groups needs to be to fit the entire group
list and will not fill in the other parameters. This is useful for
determining the exact size that ifgr_groups needs
to be in advance.