3. Recommendations
Internet host and router designers, including network product
manufacturers, should not assume that their products will be deployed
and used in only the single global Internet that they happen to
observe today. A myriad of private or future internetworks in which
these products will be used may not allow those hosts to establish
communications with arbitrary hosts on the global Internet. Since
the product failure modes resulting from an unknown future
internetwork environment cannot be fully explored, one should avoid
assumptions regarding the longevity of our current Internet.
The following recommendations are presented as best practice today.
3.1. Disable Unused Features
Vendors should, by default, disable unnecessary features in their
products. This is especially true of features that generate
unsolicited Internet traffic. In this way, these hosts will be
conservative regarding the unsolicited Internet traffic they produce.
For instance, one of the most common uses of embedded IP addresses
has been the hard-coding of addresses of well known public Simple
Network Time Protocol (SNTP RFC 2030(-> 4330) [8]) servers in products.
However, only a small fraction of users will benefit from these
products having some notion of the current date and time.
Vendors should provide an operator interface for every feature that
generates unsolicited Internet traffic. A prime example is this:
the Domain Name System resolver should have an interface enabling the
operator to either explicitly set the choice of servers or enable a
standard automated configuration protocol such as DHCP, defined by
RFC 2132draft [9]. These features should originally be disabled within
the operator interface, and subsequently enabling these features
should alert the operator that the feature exists. This will make it
more likely that the product's owner or operator can participate in
problem determination and mitigation when problems arise.
RFC 2606 [2] defines the IANA-reserved "example.com", "example.net",
and "example.org" domains for use in example configurations and
documentation. These are candidate examples to be used in user
interface documentation.
Internet hosts should use the Domain Name System to determine the IP
addresses associated with the Internet services they require.
When using domain names as service identifiers in the configurations
of deployed Internet hosts, designers and vendors are encouraged to
introduce service names. These names should be within a domain that
they either control or are permitted to utilize by an agreement with
its operator (such as for public services provided by the Internet
community). This is commonly done by introducing a service-specific
prefix to the domain name.
For instance, a vendor named "Example, Inc." with the domain
"example.com" might configure its product to find its SNTP server by
the name "sntp-server.config.example.com" or even by a name that is
specific to the product and version, such as "sntp-
server.v1.widget.config.example.com". Here the "config.example.com"
namespace is dedicated to that vendor's product configuration, with
subdomains introduced as deemed necessary. Such special-purpose
domain names enable ongoing maintenance and reconfiguration of the
services for their client hosts and can aid in the ongoing
measurement of service usage throughout the product's lifetime.
An alternative to inventing vendor-specific domain naming conventions
for a product's service identifiers is to utilize SRV resource
records (RRs), defined by RFC 2782prop [10]. SRV records are a generic
type of RR that uses a service-specific prefix in combination with a
base domain name. For example, an SRV-cognizant SNTP client might
discover Example, Inc.'s suggested NTP server by performing an SRV-
type query to lookup for "_ntp._udp.example.com".
However, note that simply hard-coding DNS name service identifiers
rather than IP addresses is not a panacea. Entries in the domain
name space are also ephemeral and can change owners for various
reasons, including acquisitions and litigation. As such, developers
and vendors should explore a product's potential failure modes
resulting from the loss of administrative control of a given domain
for whatever reason.
3.4. Use Special-Purpose, Reserved IP Addresses When Available
Default configurations, documentation, and example configurations for
Internet hosts should use Internet addresses that reside within
special blocks that have been reserved for these purposes, rather
than unique, globally-routable IP addresses. For IPv4, RFC 3330 [3]
states that the 192.0.2.0/24 block has been assigned for use in
documentation and example code. The IPv6 global unicast address
prefix 2001:DB8::/32 has been similarly reserved for documentation
purposes RFC 3849 [4]. Private Internet Addresses, as defined by RFC
1918 [5], should not be used for such purposes.
3.5. Discover and Utilize Local Services
Service providers and enterprise network operators should advertise
the identities of suitable local services, such as NTP. Very often
these services exist, but the advertisement and automated
configuration of their use is missing. For instance, the DHCP
protocol, as defined by RFC 2132draft [9], enables one to configure a
server to answer client queries for service identifiers. When local
services, including NTP, are available but not pervasively advertised
using such common protocols, designers are more likely to deploy ad
hoc initialization mechanisms that unnecessarily rely on central
services.
Operators who provide public services on the global Internet, such as
those in the NTP community, should deprecate the explicit
advertisement of the IP addresses of public services. These
addresses are ephemeral. As such, their widespread citation in
public service indexes interferes with the ability to reconfigure the
service when necessary to address unexpected, increased traffic and
the aforementioned problems.
