Connected: An Internet Encyclopedia
RFC 1812 - 1.3.4 Configuration

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1812
Up: 1. INTRODUCTION
Up: 1.3 General Considerations
Prev: 1.3.3 Error Logging
Next: 1.4 Algorithms

### 1.3.4 Configuration

In an ideal world, routers would be easy to configure, and perhaps even entirely self-configuring. However, practical experience in the real world suggests that this is an impossible goal, and that many attempts by vendors to make configuration easy actually cause customers more grief than they prevent. As an extreme example, a router designed to come up and start routing packets without requiring any configuration information at all would almost certainly choose some incorrect parameter, possibly causing serious problems on any networks unfortunate enough to be connected to it.

Often this memo requires that a parameter be a configurable option. There are several reasons for this. In a few cases there currently is some uncertainty or disagreement about the best value and it may be necessary to update the recommended value in the future. In other cases, the value really depends on external factors - e.g., the distribution of its communication load, or the speeds and topology of nearby networks - and self-tuning algorithms are unavailable and may be insufficient. In some cases, configurability is needed because of administrative requirements.

Finally, some configuration options are required to communicate with obsolete or incorrect implementations of the protocols, distributed without sources, that persist in many parts of the Internet. To make correct systems coexist with these faulty systems, administrators must occasionally misconfigure the correct systems. This problem will correct itself gradually as the faulty systems are retired, but cannot be ignored by vendors.

When we say that a parameter must be configurable, we do not intend to require that its value be explicitly read from a configuration file at every boot time. For many parameters, there is one value that is appropriate for all but the most unusual situations. In such cases, it is quite reasonable that the parameter default to that value if not explicitly set.

This memo requires a particular value for such defaults in some cases. The choice of default is a sensitive issue when the configuration item controls accommodation of existing, faulty, systems. If the Internet is to converge successfully to complete interoperability, the default values built into implementations must implement the official protocol, not misconfigurations to accommodate faulty implementations. Although marketing considerations have led some vendors to choose misconfiguration defaults, we urge vendors to choose defaults that will conform to the standard.

Finally, we note that a vendor needs to provide adequate documentation on all configuration parameters, their limits and effects.

Next: 1.4 Algorithms

Connected: An Internet Encyclopedia
RFC 1812 - 1.3.4 Configuration