projects / unix-history / blobdiff
? search:
summary | tags | clone url | shortlog | log | commit | commitdiff | tree
raw | inline | side by side
date and time created 88/06/13 15:09:44 by mckusick
[unix-history] / usr / src / share / man / man4 / netintro.4
diff --git a/usr/src/share/man/man4/netintro.4 b/usr/src/share/man/man4/netintro.4
index 3e853af..4915df0 100644 (file)
--- a/usr/src/share/man/man4/netintro.4
+++ b/usr/src/share/man/man4/netintro.4
@@ -2,9 +2,9 @@
 .\" All rights reserved.  The Berkeley software License Agreement
 .\" specifies the terms and conditions for redistribution.
 .\"
 .\" All rights reserved.  The Berkeley software License Agreement
 .\" specifies the terms and conditions for redistribution.
 .\"
-.\"    @(#)netintro.4  5.1 (Berkeley) %G%
+.\"    @(#)netintro.4  6.5 (Berkeley) %G%
 .\"
 .\"
-.TH INTRO 4N "7 July 1983"
+.TH NETINTRO 4 ""
 .UC 5
 .SH NAME
 networking \- introduction to networking facilities
 .UC 5
 .SH NAME
 networking \- introduction to networking facilities
@@ -31,39 +31,40 @@ This section briefly describes the networking facilities
 available in the system.
 Documentation in this part of section
 4 is broken up into three areas:
 available in the system.
 Documentation in this part of section
 4 is broken up into three areas:
-.IR protocol-families ,
+.I "protocol families
+(domains),
 .IR protocols ,
 and
 .IR "network interfaces" .
 .IR protocols ,
 and
 .IR "network interfaces" .
-Entries describing a protocol-family are marked ``4F'',
-while entries describing protocol use are marked ``4P''.
+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.
 .PP
 All network protocols are associated with a specific
 Hardware support for network interfaces are found
 among the standard ``4'' entries.
 .PP
 All network protocols are associated with a specific
-.IR protocol-family .
-A protocol-family provides basic services to the protocol
+.IR "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 
 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
+basic transport.  A protocol family may support multiple
 methods of addressing, though the current protocol implementations
 methods of addressing, though the current protocol implementations
-do not.  A protocol-family is normally comprised of a number
+do not.  A protocol family is normally comprised of a number
 of protocols, one per
 .IR socket (2)
 of protocols, one per
 .IR socket (2)
-type.  It is not required that a protocol-family support
-all socket types.  A protocol-family may contain multiple
+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. 
 .PP
 A protocol supports one of the socket abstractions detailed
 in
 .IR socket (2).
 A specific protocol may be accessed either by creating a
 protocols supporting the same socket abstraction. 
 .PP
 A protocol supports one of the socket abstractions detailed
 in
 .IR socket (2).
 A specific protocol may be accessed either by creating a
-socket of the appropriate type and protocol-family, or
+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
 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.
+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,
 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,
@@ -77,7 +78,7 @@ 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
 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.
+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
 The SYNOPSIS section of each network interface
 entry gives a sample specification
 of the related drivers for use in providing
@@ -85,19 +86,23 @@ a system description to the
 .IR config (8)
 program.
 The DIAGNOSTICS section lists messages which may appear on the console
 .IR config (8)
 program.
 The DIAGNOSTICS section lists messages which may appear on the console
-and in the system error log
+and/or in the system error log,
 .I /usr/adm/messages
 .I /usr/adm/messages
+(see
+.IR syslogd (8)),
 due to errors in device operation.
 .SH PROTOCOLS
 due to errors in device operation.
 .SH PROTOCOLS
-The system currently supports only the DARPA Internet
-protocols fully.  Raw socket interfaces are provided to IP protocol
+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
 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.
+the IDP protocol of Xerox NS.
 Consult the appropriate manual pages in this section for more
 information regarding the support for each protocol family.
 .SH ADDRESSING
 Associated with each protocol family is an address
 Consult the appropriate manual pages in this section for more
 information regarding the support for each protocol family.
 .SH ADDRESSING
 Associated with each protocol family is an address
-format.  The following address formats are used by the system:
+format.  The following address formats are used by the system (and additional
+formats are defined for possible future implementation):
 .sp 1
 .nf
 ._d
 .sp 1
 .nf
 ._d
@@ -105,6 +110,8 @@ format.  The following address formats are used by the system:
 #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_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 */
 .fi
 .SH ROUTING
 The network facilities provided limited packet routing.
 .fi
 .SH ROUTING
 The network facilities provided limited packet routing.
@@ -113,7 +120,7 @@ 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 process,
 the routing daemon, maintains this data base with the aid
 transmitting packets.  This table contains a single entry for
 each route to a specific network or host.  A user process,
 the routing daemon, maintains this data base with the aid
-of two socket specific 
+of two socket-specific 
 .IR ioctl (2)
 commands, SIOCADDRT and SIOCDELRT.  The commands allow
 the addition and deletion of a single routing
 .IR ioctl (2)
 commands, SIOCADDRT and SIOCDELRT.  The commands allow
 the addition and deletion of a single routing
@@ -146,21 +153,22 @@ 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_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) */
 .fi
 .PP
 Routing table entries come in three flavors: for a specific
 host, for all hosts on a specific network, for any destination
 not matched by entries of the first two types (a wildcard route). 
 .fi
 .PP
 Routing table entries come in three flavors: for a specific
 host, for all hosts on a specific network, for any destination
 not matched by entries of the first two types (a wildcard route). 
-When the system
-is booted, each network interface autoconfigured 
-installs a routing table entry when it wishes to have packets
-sent through it.  Normally the interface specifies the route
-through it is a ``direct'' connection to the destination host
+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
 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).
+is requested to address the packet to the gateway listed in the routing entry
+(i.e. the packet is forwarded).
 .PP
 Routing table entries installed by a user process may not specify
 the hash, reference count, use, or interface fields; these are filled
 .PP
 Routing table entries installed by a user process may not specify
 the hash, reference count, use, or interface fields; these are filled
@@ -168,25 +176,28 @@ in by the routing routines.  If
 a route is in use when it is deleted
 .RI ( rt_refcnt
 is non-zero),
 a route is in use when it is deleted
 .RI ( rt_refcnt
 is non-zero),
-the resources associated with it will not
-be reclaimed until further references to it are released. 
-.PP
+the routing 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 routing code returns EEXIST if
 requested to duplicate an existing entry, ESRCH if
 The routing code returns EEXIST if
 requested to duplicate an existing entry, ESRCH if
-requested to delete a non-existant entry,
+requested to delete a non-existent entry,
 or ENOBUFS if insufficient resources were available
 to install a new route.
 or ENOBUFS if insufficient resources were available
 to install a new route.
-.PP
 User processes read the routing tables through the
 .I /dev/kmem 
 device.
 User processes read the routing tables through the
 .I /dev/kmem 
 device.
-.PP
 The
 .I rt_use
 field contains the number of packets sent along the route.
 The
 .I 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.
+.PP
+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.
 .PP
 A wildcard routing entry is specified with a zero
 destination address value.  Wildcard routes are used
 .PP
 A wildcard routing entry is specified with a zero
 destination address value.  Wildcard routes are used
@@ -202,64 +213,76 @@ certain interfaces such as the loopback interface,
 .IR lo (4),
 do not.
 .PP
 .IR lo (4),
 do not.
 .PP
-At boot time each interface which has underlying hardware support
-makes itself known to the system during the autoconfiguration
-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 SIOCSIFADDR 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.
-.PP
 The following 
 .I ioctl
 The following 
 .I ioctl
-calls may be used to manipulate network interfaces.  Unless
-specified otherwise, the request takes an
+calls may be used to manipulate network interfaces.
+The
+.I ioctl
+is made on a socket (typically of type SOCK_DGRAM)
+in the desired domain.
+Unless specified otherwise, the request takes an
 .I ifrequest
 structure as its parameter.  This structure has the form
 .PP
 .nf
 .DT
 struct ifreq {
 .I ifrequest
 structure as its parameter.  This structure has the form
 .PP
 .nf
 .DT
 struct ifreq {
-       char    ifr_name[16];           /* name of interface (e.g. "ec0") */
+#define        IFNAMSIZ        16
+       char    ifr_name[IFNAMSIZE];            /* if name, e.g. "en0" */
        union {
                struct  sockaddr ifru_addr;
                struct  sockaddr ifru_dstaddr;
        union {
                struct  sockaddr ifru_addr;
                struct  sockaddr ifru_dstaddr;
+               struct  sockaddr ifru_broadaddr;
                short   ifru_flags;
                short   ifru_flags;
+               int     ifru_metric;
+               caddr_t ifru_data;
        } ifr_ifru;
 #define        ifr_addr        ifr_ifru.ifru_addr      /* address */
 #define        ifr_dstaddr     ifr_ifru.ifru_dstaddr   /* other end of p-to-p link */
        } 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_flags       ifr_ifru.ifru_flags     /* flags */
+#define        ifr_metric      ifr_ifru.ifru_metric    /* metric */
+#define        ifr_data        ifr_ifru.ifru_data      /* for use by interface */
 };
 .fi
 .TP
 SIOCSIFADDR
 };
 .fi
 .TP
 SIOCSIFADDR
-Set interface address.  Following the address
+Set interface address for protocol family.  Following the address
 assignment, the ``initialization'' routine for
 the interface is called.
 .TP
 SIOCGIFADDR
 assignment, the ``initialization'' routine for
 the interface is called.
 .TP
 SIOCGIFADDR
-Get interface address.
+Get interface address for protocol family.
 .TP
 SIOCSIFDSTADDR
 .TP
 SIOCSIFDSTADDR
-Set point to point address for interface.
+Set point to point address for protocol family and interface.
 .TP
 SIOCGIFDSTADDR
 .TP
 SIOCGIFDSTADDR
-Get point to point address for interface.
+Get point to point address for protocol family and interface.
+.TP
+SIOCSIFBRDADDR
+Set broadcast address for protocol family and interface.
+.TP
+SIOCGIFBRDADDR
+Get broadcast address for protocol family and interface.
 .TP
 SIOCSIFFLAGS
 Set interface flags field.  If the interface is marked down,
 any processes currently routing packets through the interface
 .TP
 SIOCSIFFLAGS
 Set interface flags field.  If the interface is marked down,
 any processes currently routing packets through the interface
-are notified.
+are notified;
+some interfaces may be reset so that incoming packets are no longer received.
+When marked up again, the interface is reinitialized.
 .TP
 SIOCGIFFLAGS
 Get interface flags.
 .TP
 .TP
 SIOCGIFFLAGS
 Get interface flags.
 .TP
+SIOCSIFMETRIC
+Set interface routing metric.
+The metric is used only by user-level routers.
+.TP
+SIOCGIFMETRIC
+Get interface metric.
+.TP
 SIOCGIFCONF
 Get interface configuration list.  This request takes an
 .I ifconf
 SIOCGIFCONF
 Get interface configuration list.  This request takes an
 .I ifconf
@@ -290,8 +313,4 @@ struct      ifconf {
 };
 .fi
 .SH SEE ALSO
 };
 .fi
 .SH SEE ALSO
-socket(2),
-ioctl(2),
-intro(4),
-config(8),
-routed(8C)
+socket(2), ioctl(2), intro(4), config(8), routed(8C)
Continuous source code history from original PDP-7 UNIX to FreeBSD 2, the first fully unencumbered FreeBSD release.