install correct aliases file
[unix-history] / usr / src / usr.sbin / config / SMM.doc / e.t
CommitLineData
57349e41
MK
1.\" Copyright (c) 1986 Regents of the University of California.
2.\" All rights reserved. The Berkeley software License Agreement
3.\" specifies the terms and conditions for redistribution.
4.\"
2577f725 5.\" @(#)e.t 6.2 (Berkeley) %G%
57349e41
MK
6.\"
7.\".ds RH "Network configuration options
8.bp
9.LG
10.B
11.ce
12APPENDIX E. NETWORK CONFIGURATION OPTIONS
13.sp
14.R
15.NL
16.PP
2577f725 17The network support in the kernel is self-configuring
57349e41
MK
18according to the protocol support options (INET and NS) and the network
19hardware discovered during autoconfiguration.
20There are several changes that may be made to customize network behavior
21due to local restrictions.
22Within the Internet protocol routines, the following options
23set in the system configuration file are supported:
24.IP \fBGATEWAY\fP
25.br
26The machine is to be used as a gateway.
27This option currently makes only minor changes.
28First, the size of the network routing hash table is increased.
29Secondly, machines that have only a single hardware network interface
30will not forward IP packets; without this option, they will also refrain
31from sending any error indication to the source of unforwardable packets.
32Gateways with only a single interface are assumed to have missing
33or broken interfaces, and will return ICMP unreachable errors to hosts
34sending them packets to be forwarded.
35.IP \fBTCP_COMPAT_42\fP
36.br
37This option forces the system to limit its initial TCP sequence numbers
38to positive numbers.
39Without this option, 4.3BSD systems may have problems with TCP connections
40to 4.2BSD systems that connect but never transfer data.
41The problem is a bug in the 4.2BSD TCP; this option should be used
42during the period of conversion to 4.3BSD.
43.IP \fBIPFORWARDING\fP
44.br
45Normally, 4.3BSD machines with multiple network interfaces
46will forward IP packets received that should be resent to another host.
47If the line ``options IPFORWARDING="0"'' is in the system configuration
48file, IP packet forwarding will be disabled.
49.IP \fBIPSENDREDIRECTS\fP
50.br
51When forwarding IP packets, 4.3BSD IP will note when a packet is forwarded
52using the same interface on which it arrived.
53When this is noted, if the source machine is on the directly-attached
54network, an ICMP redirect is sent to the source host.
55If the packet was forwarded using a route to a host or to a subnet,
56a host redirect is sent, otherwise a network redirect is sent.
57The generation of redirects may be inhibited with the configuration
58option ``options IPSENDREDIRECTS="0".''
59.br
60.IP \fBSUBNETSARELOCAL\fP
61TCP calculates a maximum segment size to use for each connection,
62and sends no datagrams larger than that size.
63This size will be no larger than that supported on the outgoing
64interface.
65Furthermore, if the destination is not on the local network,
66the size will be no larger than 576 bytes.
67For this test, other subnets of a directly-connected subnetted
68network are considered to be local unless the line
69``options SUBNETSARELOCAL="0"'' is used in the system configuration file.
70.IP \fBCOMPAT_42\fP
71.br
72This option, intended as a catchall for 4.2BSD compatibility options,
73has only a single function thus far.
74It disables the checking of UDP input packet checksums.
75As the calculation of UDP packet checksums was incorrect in 4.2BSD,
76this option allows a 4.3BSD system to receive UDP packets from
77a 4.2BSD system.
78.LP
79The following options are supported by the Xerox NS protocols:
80.IP \fBNSIP\fP
81.br
82This option allows NS IDP datagrams to be encapsulated in Internet IP
83packets for transmission to a collaborating NSIP host.
84This may be used to pass IDP packets through IP-only link layer networks.
85See
86.IR nsip (4P)
87for details.
88.IP \fBTHREEWAYSHAKE\fP
89.br
90The NS Sequenced Packet Protocol does not require a three-way handshake
91before considering a connection to be in the established state.
92(A three-way handshake consists of a connection request, an acknowledgement
93of the request along with a symmetrical opening indication,
94and then an acknowledgement of the reciprocal opening packet.)
95This option forces a three-way handshake before data may be transmitted
96on Sequenced Packet sockets.