summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5505.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5505.txt')
-rw-r--r--doc/rfc/rfc5505.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc5505.txt b/doc/rfc/rfc5505.txt
new file mode 100644
index 0000000..d529844
--- /dev/null
+++ b/doc/rfc/rfc5505.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group B. Aboba
+Request for Comments: 5505 D. Thaler
+Category: Informational L. Andersson
+ S. Cheshire
+ Internet Architecture Board
+ May 2009
+
+
+ Principles of Internet Host Configuration
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+Abstract
+
+ This document describes principles of Internet host configuration.
+ It covers issues relating to configuration of Internet-layer
+ parameters, as well as parameters affecting higher-layer protocols.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Informational [Page 1]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Terminology ................................................3
+ 1.2. Internet Host Configuration ................................4
+ 1.2.1. Internet-Layer Configuration ........................4
+ 1.2.2. Higher-Layer Configuration ..........................6
+ 2. Principles ......................................................7
+ 2.1. Minimize Configuration .....................................7
+ 2.2. Less Is More ...............................................7
+ 2.3. Minimize Diversity .........................................8
+ 2.4. Lower-Layer Independence ...................................9
+ 2.5. Configuration Is Not Access Control .......................11
+ 3. Additional Discussion ..........................................12
+ 3.1. Reliance on General-Purpose Mechanisms ....................12
+ 3.2. Relationship between IP Configuration and Service
+ Discovery .................................................13
+ 3.2.1. Fate Sharing .......................................14
+ 3.3. Discovering Names versus Addresses ........................15
+ 3.4. Dual-Stack Issues .........................................15
+ 3.5. Relationship between Per-Interface and Per-Host
+ Configuration .............................................16
+ 4. Security Considerations ........................................17
+ 4.1. Configuration Authentication ..............................18
+ 5. Informative References .........................................19
+ Appendix A. Acknowledgments .......................................24
+ Appendix B. IAB Members at the Time of This Writing ...............24
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Informational [Page 2]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+1. Introduction
+
+ This document describes principles of Internet host [STD3]
+ configuration. It covers issues relating to configuration of
+ Internet-layer parameters, as well as parameters affecting higher-
+ layer protocols.
+
+ In recent years, a number of architectural questions have arisen, for
+ which we provide guidance to protocol developers:
+
+ o The protocol layers and general approaches that are most
+ appropriate for configuration of various parameters.
+
+ o The relationship between parameter configuration and service
+ discovery.
+
+ o The relationship between per-interface and per-host configuration.
+
+ o The relationship between network access authentication and host
+ configuration.
+
+ o The desirability of supporting self-configuration of parameters or
+ avoiding parameter configuration altogether.
+
+ o The role of link-layer protocols and tunneling protocols in
+ Internet host configuration.
+
+ The role of the link-layer and tunneling protocols is particularly
+ important, since it can affect the properties of a link as seen by
+ higher layers (for example, whether privacy extensions [RFC4941] are
+ available to applications).
+
+1.1. Terminology
+
+ link
+
+ A communication facility or medium over which nodes can
+ communicate at the link layer, i.e., the layer immediately below
+ IP. Examples are Ethernets (simple or bridged), Point-to-Point
+ Protocol (PPP) links, X.25, Frame Relay, or ATM networks as well
+ as Internet- or higher-layer "tunnels", such as tunnels over IPv4
+ or IPv6 itself.
+
+ on link
+
+ An address that is assigned to an interface on a specified link.
+
+
+
+
+
+Aboba, et al. Informational [Page 3]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ off link
+
+ The opposite of "on link"; an address that is not assigned to any
+ interfaces on the specified link.
+
+ mobility agent
+
+ Either a home agent or a foreign agent [RFC3344] [RFC3775].
+
+1.2. Internet Host Configuration
+
+1.2.1. Internet-Layer Configuration
+
+ Internet-layer configuration is defined as the configuration required
+ to support the operation of the Internet layer. This includes
+ configuration of per-interface and per-host parameters, including IP
+ address(es), subnet prefix(es), default gateway(s), mobility
+ agent(s), boot service configuration and other parameters:
+
+ IP address(es)
+
+ Internet Protocol (IP) address configuration includes both
+ configuration of link-scope addresses as well as global addresses.
+ Configuration of IP addresses is a vital step, since practically
+ all of IP networking relies on the assumption that hosts have IP
+ address(es) associated with (each of) their active network
+ interface(s). Used as the source address of an IP packet, these
+ IP addresses indicate the sender of the packet; used as the
+ destination address of a unicast IP packet, these IP addresses
+ indicate the intended receiver.
+
+ The only common example of IP-based protocols operating without an
+ IP address involves address configuration, such as the use of
+ DHCPv4 [RFC2131] to obtain an address. In this case, by
+ definition, DHCPv4 is operating before the host has an IPv4
+ address, so the DHCP protocol designers had the choice of either
+ using IP without an IP address, or not using IP at all. The
+ benefits of making IPv4 self-reliant, configuring itself using its
+ own IPv4 packets, instead of depending on some other protocol,
+ outweighed the drawbacks of having to use IP in this constrained
+ mode. Use of IP for purposes other than address configuration can
+ safely assume that the host will have one or more IP addresses,
+ which may be self-configured link-local addresses [RFC3927]
+ [RFC4862], or other addresses configured via DHCP or other means.
+
+
+
+
+
+
+
+Aboba, et al. Informational [Page 4]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ Subnet prefix(es)
+
+ Once a subnet prefix is configured on an interface, hosts with an
+ IP address can exchange unicast IP packets directly with on-link
+ hosts within the same subnet prefix.
+
+ Default gateway(s)
+
+ Once a default gateway is configured on an interface, hosts with
+ an IP address can send unicast IP packets to that gateway for
+ forwarding to off-link hosts.
+
+ Mobility agent(s)
+
+ While Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] include
+ their own mechanisms for locating home agents, it is also possible
+ for mobile nodes to utilize dynamic home agent configuration.
+
+ Boot service configuration
+
+ Boot service configuration is defined as the configuration
+ necessary for a host to obtain and perhaps also to verify an
+ appropriate boot image. This is appropriate for disk-less hosts
+ looking to obtain a boot image via mechanisms such as the Trivial
+ File Transfer Protocol (TFTP) [RFC1350], Network File System (NFS)
+ [RFC3530], and Internet Small Computer Systems Interface (iSCSI)
+ [RFC3720] [RFC4173]. It also may be useful in situations where it
+ is necessary to update the boot image of a host that supports a
+ disk, such as in the Preboot Execution Environment [PXE]
+ [RFC4578]. While strictly speaking, boot services operate above
+ the Internet layer, where boot service is used to obtain the
+ Internet-layer code, it may be considered part of Internet-layer
+ configuration. While boot service parameters may be provided on a
+ per-interface basis, loading and verification of a boot image
+ affects behavior of the host as a whole.
+
+ Other IP parameters
+
+ Internet-layer parameter configuration also includes configuration
+ of per-host parameters (e.g., hostname) and per-interface
+ parameters (e.g., IP Time-To-Live (TTL) to use in outgoing
+ packets, enabling/disabling of IP forwarding and source routing,
+ and Maximum Transmission Unit (MTU)).
+
+
+
+
+
+
+
+
+Aboba, et al. Informational [Page 5]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+1.2.2. Higher-Layer Configuration
+
+ Higher-layer configuration is defined as the configuration required
+ to support the operation of other components above the Internet-
+ layer. This includes, for example:
+
+ Name Service Configuration
+
+ The configuration required for the host to resolve names. This
+ includes configuration of the addresses of name resolution
+ servers, including IEN 116 [IEN116], Domain Name System (DNS),
+ Windows Internet Name Service (WINS), Internet Storage Name
+ Service (iSNS) [RFC4171] [RFC4174], and Network Information
+ Service (NIS) servers [RFC3898], and the setting of name
+ resolution parameters such as the DNS domain and search list
+ [RFC3397], the NetBIOS node type, etc. It may also include the
+ transmission or setting of the host's own name. Note that link-
+ local name resolution services (such as NetBIOS [RFC1001], Link-
+ Local Multicast Name Resolution (LLMNR) [RFC4795], and multicast
+ DNS (mDNS) [mDNS]) typically do not require configuration.
+
+ Once the host has completed name service configuration, it is
+ capable of resolving names using name resolution protocols that
+ require configuration. This not only allows the host to
+ communicate with off-link hosts whose IP addresses are not known,
+ but, to the extent that name services requiring configuration are
+ utilized for service discovery, also enables the host to discover
+ services available on the network or elsewhere. While name
+ service parameters can be provided on a per-interface basis, their
+ configuration will typically affect behavior of the host as a
+ whole.
+
+ Time Service Configuration
+
+ Time service configuration includes configuration of servers for
+ protocols such as the Simple Network Time Protocol (SNTP) and the
+ Network Time Protocol (NTP). Since accurate determination of the
+ time may be important to operation of the applications running on
+ the host (including security services), configuration of time
+ servers may be a prerequisite for higher-layer operation.
+ However, it is typically not a requirement for Internet-layer
+ configuration. While time service parameters can be provided on a
+ per-interface basis, their configuration will typically affect
+ behavior of the host as a whole.
+
+
+
+
+
+
+
+Aboba, et al. Informational [Page 6]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ Other service configuration
+
+ This can include discovery of additional servers and devices, such
+ as printers, Session Initiation Protocol (SIP) proxies, etc. This
+ configuration will typically apply to the entire host.
+
+2. Principles
+
+ This section describes basic principles of Internet host
+ configuration.
+
+2.1. Minimize Configuration
+
+ Anything that can be configured can be misconfigured. Section 3.8 of
+ "Architectural Principles of the Internet" [RFC1958] states: "Avoid
+ options and parameters whenever possible. Any options and parameters
+ should be configured or negotiated dynamically rather than manually."
+
+ That is, to minimize the possibility of configuration errors,
+ parameters should be automatically computed (or at least have
+ reasonable defaults) whenever possible. For example, the Path
+ Maximum Transmission Unit (PMTU) can be discovered, as described in
+ "Packetization Layer Path MTU Discovery" [RFC4821], "TCP Problems
+ with Path MTU Discovery" [RFC2923], "Path MTU discovery" [RFC1191],
+ and "Path MTU Discovery for IP version 6" [RFC1981].
+
+ Having a protocol design with many configurable parameters increases
+ the possibilities for misconfiguration of those parameters, resulting
+ in failures or other sub-optimal operation. Eliminating or reducing
+ configurable parameters helps lessen this risk. Where configurable
+ parameters are necessary or desirable, protocols can reduce the risk
+ of human error by making these parameters self-configuring, such as
+ by using capability negotiation within the protocol, or by automated
+ discovery of other hosts that implement the same protocol.
+
+2.2. Less Is More
+
+ The availability of standardized, simple mechanisms for general-
+ purpose Internet host configuration is highly desirable.
+ "Architectural Principles of the Internet" [RFC1958] states,
+ "Performance and cost must be considered as well as functionality"
+ and "Keep it simple. When in doubt during design, choose the
+ simplest solution."
+
+ To allow protocol support in many types of devices, it is important
+ to minimize the footprint requirement. For example, IP-based
+ protocols are used on a wide range of devices, from supercomputers to
+ small low-cost devices running "embedded" operating systems. Since
+
+
+
+Aboba, et al. Informational [Page 7]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ the resources (e.g., memory and code size) available for host
+ configuration may be very small, it is desirable for a host to be
+ able to configure itself in as simple a manner as possible.
+
+ One interesting example is IP support in preboot execution
+ environments. Since by definition boot configuration is required in
+ hosts that have not yet fully booted, it is often necessary for pre-
+ boot code to be executed from Read Only Memory (ROM), with minimal
+ available memory. Many hosts do not have enough space in this ROM
+ for even a simple implementation of TCP, so in the Preboot Execution
+ Environment (PXE) the task of obtaining a boot image is performed
+ using the User Datagram Protocol over IP (UDP/IP) [RFC768] instead.
+ This is one reason why Internet-layer configuration mechanisms
+ typically depend only on IP and UDP. After obtaining the boot image,
+ the host will have the full facilities of TCP/IP available to it,
+ including support for reliable transport protocols, IPsec, etc.
+
+ In order to reduce complexity, it is desirable for Internet-layer
+ configuration mechanisms to avoid dependencies on higher layers.
+ Since embedded devices may be severely constrained on how much code
+ they can fit within their ROM, designing a configuration mechanism in
+ such a way that it requires the availability of higher-layer
+ facilities may make that configuration mechanism unusable in such
+ devices. In fact, it cannot even be guaranteed that all Internet-
+ layer facilities will be available. For example, the minimal version
+ of IP in a host's boot ROM may not implement IP fragmentation and
+ reassembly.
+
+2.3. Minimize Diversity
+
+ The number of host configuration mechanisms should be minimized.
+ Diversity in Internet host configuration mechanisms presents several
+ problems:
+
+ Interoperability
+
+ As configuration diversity increases, it becomes likely that a
+ host will not support the configuration mechanism(s) available on
+ the network to which it has attached, creating interoperability
+ problems.
+
+ Footprint
+
+ For maximum interoperability, a host would need to implement all
+ configuration mechanisms used on all the link layers it supports.
+ This increases the required footprint, a burden for embedded
+ devices. It also leads to lower quality, since testing resources
+
+
+
+
+Aboba, et al. Informational [Page 8]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ (both formal testing, and real-world operational use) are spread
+ more thinly -- the more different configuration mechanisms a
+ device supports, the less testing each one is likely to undergo.
+
+ Redundancy
+
+ To support diversity in host configuration mechanisms, operators
+ would need to support multiple configuration services to ensure
+ that hosts connecting to their networks could configure
+ themselves. This represents an additional expense for little
+ benefit.
+
+ Latency
+
+ As configuration diversity increases, hosts supporting multiple
+ configuration mechanisms may spend increasing effort to determine
+ which mechanism(s) are supported. This adds to configuration
+ latency.
+
+ Conflicts
+
+ Whenever multiple mechanisms are available, it is possible that
+ multiple configurations will be returned. To handle this, hosts
+ would need to merge potentially conflicting configurations. This
+ would require conflict-resolution logic, such as ranking of
+ potential configuration sources, increasing implementation
+ complexity.
+
+ Additional traffic
+
+ To limit configuration latency, hosts may simultaneously attempt
+ to obtain configuration by multiple mechanisms. This can result
+ in increasing on-the-wire traffic, both from use of multiple
+ mechanisms as well as from retransmissions within configuration
+ mechanisms not implemented on the network.
+
+ Security
+
+ Support for multiple configuration mechanisms increases the attack
+ surface without any benefit.
+
+2.4. Lower-Layer Independence
+
+ "Architectural Principles of the Internet" [RFC1958] states,
+ "Modularity is good. If you can keep things separate, do so."
+
+
+
+
+
+
+Aboba, et al. Informational [Page 9]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ It is becoming increasingly common for hosts to support multiple
+ network access mechanisms, including dialup, wireless, and wired
+ local area networks; wireless metropolitan and wide area networks;
+ etc. The proliferation of network access mechanisms makes it
+ desirable for hosts to be able to configure themselves on multiple
+ networks without adding configuration code specific to each new link
+ layer.
+
+ As a result, it is highly desirable for Internet host configuration
+ mechanisms to be independent of the underlying lower layer. That is,
+ only the link-layer protocol (whether it be a physical link or a
+ virtual tunnel link) should be explicitly aware of link-layer
+ parameters (although those link-layer parameters may be configured by
+ general Internet-layer mechanisms). Introduction of lower-layer
+ dependencies increases the likelihood of interoperability problems
+ and adds Internet-layer configuration mechanisms that hosts need to
+ implement.
+
+ Lower-layer dependencies can be best avoided by keeping Internet host
+ configuration above the link layer, thereby enabling configuration to
+ be handled for any link layer that supports IP. In order to provide
+ media independence, Internet host configuration mechanisms should be
+ link-layer protocol independent.
+
+ While there are examples of Internet-layer configuration within the
+ link layer (such as in PPP IPv4CP [RFC1332] and "Mobile radio
+ interface Layer 3 specification; Core network protocols; Stage 3
+ (Release 5)" [3GPP-24.008]), this approach has disadvantages. These
+ include the extra complexity of implementing different mechanisms on
+ different link layers and the difficulty in adding new higher-layer
+ parameters that would require defining a mechanism in each link-layer
+ protocol.
+
+ For example, "PPP Internet Protocol Control Protocol Extensions for
+ Name Server Addresses" [RFC1877] was developed prior to the
+ definition of the DHCPINFORM message in "Dynamic Host Configuration
+ Protocol" [RFC2131]; at that time, Dynamic Host Configuration
+ Protocol (DHCP) servers had not been widely implemented on access
+ devices or deployed in service provider networks. While the design
+ of IPv4CP was appropriate in 1992, it should not be taken as an
+ example that new link-layer technologies should emulate. Indeed, in
+ order to "actively advance PPP's most useful extensions to full
+ standard, while defending against further enhancements of
+ questionable value", "IANA Considerations for the Point-to-Point
+ Protocol (PPP)" [RFC3818] changed the allocation of PPP numbers
+ (including IPv4CP extensions) so as to no longer be "first come first
+ served".
+
+
+
+
+Aboba, et al. Informational [Page 10]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ In IPv6, where link-layer-independent mechanisms such as stateless
+ autoconfiguration [RFC4862] and stateless DHCPv6 [RFC3736] are
+ available, PPP IPv6CP [RFC5072] configures an Interface-Identifier
+ that is similar to a Media Access Control (MAC) address. This
+ enables PPP IPv6CP to avoid duplicating DHCPv6 functionality.
+
+ However, Internet Key Exchange Version 2 (IKEv2) [RFC4306] utilizes
+ the same approach as PPP IPv4CP by defining a Configuration Payload
+ for Internet host configuration for both IPv4 and IPv6. While the
+ IKEv2 approach reduces the number of packet exchanges, "Dynamic Host
+ Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode"
+ [RFC3456] points out that leveraging DHCP has advantages in terms of
+ address management integration, address pool management,
+ reconfiguration, and fail-over.
+
+ Extensions to link-layer protocols for the purpose of Internet-,
+ transport-, or application-layer configuration (including server
+ configuration) should be avoided. Such extensions can negatively
+ affect the properties of a link as seen by higher layers. For
+ example, if a link-layer protocol (or tunneling protocol) configures
+ individual IPv6 addresses and precludes using any other addresses,
+ then applications that want to use privacy extensions [RFC4941] may
+ not function well. Similar issues may arise for other types of
+ addresses, such as Cryptographically Generated Addresses [RFC3972].
+
+ Avoiding lower-layer dependencies is desirable even where the lower
+ layer is link independent. For example, while the Extensible
+ Authentication Protocol (EAP) may be run over any link satisfying its
+ requirements (see Section 3.1 of [RFC3748]), many link layers do not
+ support EAP and therefore Internet-layer configuration mechanisms
+ that depend on EAP would not be usable on links that support IP but
+ not EAP.
+
+2.5. Configuration Is Not Access Control
+
+ Network access authentication and authorization is a distinct problem
+ from Internet host configuration. Therefore, network access
+ authentication and authorization is best handled independently of the
+ Internet and higher-layer configuration mechanisms.
+
+ Having an Internet- or higher-layer protocol authenticate clients is
+ appropriate to prevent resource exhaustion of a scarce resource on
+ the server (such as IP addresses or prefixes), but not for preventing
+ hosts from obtaining access to a link. If the user can manually
+ configure the host, requiring authentication in order to obtain
+ configuration parameters (such as an IP address) has little value.
+ Network administrators who wish to control access to a link can
+ better achieve this using technologies like Port-Based Network Access
+
+
+
+Aboba, et al. Informational [Page 11]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ Control [IEEE-802.1X]. Note that client authentication is not
+ required for Stateless DHCPv6 [RFC3736] since it does not result in
+ allocation of any limited resources on the server.
+
+3. Additional Discussion
+
+3.1. Reliance on General-Purpose Mechanisms
+
+ Protocols should either be self-configuring (especially where fate
+ sharing is important), or use general-purpose configuration
+ mechanisms (such as DHCP or a service discovery protocol, as noted in
+ Section 3.2). The choice should be made taking into account the
+ architectural principles discussed in Section 2.
+
+ Taking into account the general-purpose configuration mechanisms
+ currently available, we see little need for development of additional
+ general-purpose configuration mechanisms.
+
+ When defining a new host parameter, protocol designers should first
+ consider whether configuration is indeed necessary (see Section 2.1).
+
+ If configuration is necessary, in addition to considering fate
+ sharing (see Section 3.2.1), protocol designers should consider:
+
+ 1. The organizational implications for administrators. For example,
+ routers and servers are often administered by different sets of
+ individuals, so that configuring a router with server parameters
+ may require cross-group collaboration.
+
+ 2. Whether the need is to configure a set of interchangeable servers
+ or to select a particular server satisfying a set of criteria.
+ See Section 3.2.
+
+ 3. Whether IP address(es) should be configured, or name(s). See
+ Section 3.3.
+
+ 4. If IP address(es) are configured, whether IPv4 and IPv6 addresses
+ should be configured simultaneously or separately. See Section
+ 3.4.
+
+ 5. Whether the parameter is a per-interface or a per-host parameter.
+ For example, configuration protocols such as DHCP run on a per-
+ interface basis and hence are more appropriate for per-interface
+ parameters.
+
+
+
+
+
+
+
+Aboba, et al. Informational [Page 12]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ 6. How per-interface configuration affects host-wide behavior. For
+ example, whether the host should select a subset of the per-
+ interface configurations, or whether the configurations are to
+ merged, and if so, how this is done. See Section 3.5.
+
+3.2. Relationship between IP Configuration and Service Discovery
+
+ Higher-layer configuration often includes configuring server
+ addresses. The question arises as to how this differs from "service
+ discovery" as provided by Service Discovery protocols such as
+ "Service Location Protocol, Version 2" (SLPv2) [RFC2608] or "DNS-
+ Based Service Discovery" (DNS-SD) [DNS-SD].
+
+ In Internet host configuration mechanisms such as DHCP, if multiple
+ server instances are provided, they are considered interchangeable.
+ For example, in a list of time servers, the servers are considered
+ interchangeable because they all provide the exact same service --
+ telling you the current time. In a list of local caching DNS
+ servers, the servers are considered interchangeable because they all
+ should give you the same answer to any DNS query. In service
+ discovery protocols, on the other hand, a host desires to find a
+ server satisfying a particular set of criteria, which may vary by
+ request. When printing a document, it is not the case that any
+ printer will do. The speed, capabilities, and physical location of
+ the printer matter to the user.
+
+ Information learned via DHCP is typically learned once, at boot time,
+ and after that may be updated only infrequently (e.g., on DHCP lease
+ renewal), if at all. This makes DHCP appropriate for information
+ that is relatively static and unchanging over these time intervals.
+ Boot-time discovery of server addresses is appropriate for service
+ types where there are a small number of interchangeable servers that
+ are of interest to a large number of clients. For example, listing
+ time servers in a DHCP packet is appropriate because an organization
+ may typically have only two or three time servers, and most hosts
+ will be able to make use of that service. Listing all the printers
+ or file servers at an organization is a lot less useful, because the
+ list may contain hundreds or thousands of entries, and on a given day
+ a given user may not use any of the printers in that list.
+
+ Service discovery protocols can support discovery of servers on the
+ Internet, not just those within the local administrative domain. For
+ example, see "Remote Service Discovery in the Service Location
+ Protocol (SLP) via DNS SRV" [RFC3832] and DNS-Based Service Discovery
+ [DNS-SD]. Internet host configuration mechanisms such as DHCP, on
+ the other hand, typically assume the server or servers in the local
+ administrative domain contain the authoritative set of information.
+
+
+
+
+Aboba, et al. Informational [Page 13]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ For the service discovery problem (i.e., where the criteria varies on
+ a per-request basis, even from the same host), protocols should
+ either be self-discovering (if fate sharing is critical), or use a
+ general-purpose service discovery mechanism.
+
+ In order to avoid a dependency on multicast routing, it is necessary
+ for a host to either restrict discovery to services on the local link
+ or to discover the location of a Directory Agent (DA). Since the DA
+ may not be available on the local link, service discovery beyond the
+ local link is typically dependent on a mechanism for configuring the
+ DA address or name. As a result, service discovery protocols can
+ typically not be relied upon for obtaining basic Internet-layer
+ configuration, although they can be used to obtain higher-layer
+ configuration parameters.
+
+3.2.1. Fate Sharing
+
+ If a server (or set of servers) is needed to get a set of
+ configuration parameters, "fate sharing" (Section 2.3 of [RFC1958])
+ is preserved if those parameters are ones that cannot be usefully
+ used without those servers being available. In this case,
+ successfully obtaining those parameters via other means has little
+ benefit if they cannot be used because the required servers are not
+ available. The possibility of incorrect information being configured
+ is minimized if there is only one machine that is authoritative for
+ the information (i.e., there is no need to keep multiple
+ authoritative servers in sync). For example, learning default
+ gateways via Router Advertisements provides perfect fate sharing.
+ That is, gateway addresses can be obtained if and only if they can
+ actually be used. Similarly, obtaining DNS server configuration from
+ a DNS server would provide fate sharing since the configuration would
+ only be obtainable if the DNS server were available.
+
+ While fate sharing is a desirable property of a configuration
+ mechanism, in some situations fate sharing may not be possible. When
+ utilized to discover services on the local link, service discovery
+ protocols typically provide for fate sharing, since hosts providing
+ service information typically also provide the services. However,
+ this is no longer the case when service discovery is assisted by a
+ Directory Agent (DA). First of all, the DA's list of operational
+ servers may not be current, so it is possible that the DA may provide
+ clients with service information that is out of date. For example, a
+ DA's response to a client's service discovery query may contain stale
+ information about servers that are no longer operational. Similarly,
+ recently introduced servers might not yet have registered themselves
+ with the DA. Furthermore, the use of a DA for service discovery also
+ introduces a dependency on whether the DA is operational, even though
+ the DA is typically not involved in the delivery of the service.
+
+
+
+Aboba, et al. Informational [Page 14]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ Similar limitations exist for other server-based configuration
+ mechanisms such as DHCP. Typically DHCP servers do not check for the
+ liveness of the configuration information they provide, and do not
+ discover new configuration information automatically. As a result,
+ there is no guarantee that configuration information will be current.
+
+ Section 3.3 of "IPv6 Host Configuration of DNS Server Information
+ Approaches" [RFC4339] discusses the use of well-known anycast
+ addresses for discovery of DNS servers. The use of anycast addresses
+ enables fate sharing, even where the anycast address is provided by
+ an unrelated server. However, in order to be universally useful,
+ this approach would require allocation of one or more well-known
+ anycast addresses for each service. Configuration of more than one
+ anycast address is desirable to allow the client to fail over faster
+ than would be possible from routing protocol convergence.
+
+3.3. Discovering Names vs. Addresses
+
+ In discovering servers other than name resolution servers, it is
+ possible to either discover the IP addresses of the server(s), or to
+ discover names, each of which may resolve to a list of addresses.
+
+ It is typically more efficient to obtain the list of addresses
+ directly, since this avoids the extra name resolution steps and
+ accompanying latency. On the other hand, where servers are mobile,
+ the name-to-address binding may change, requiring a fresh set of
+ addresses to be obtained. Where the configuration mechanism does not
+ support fate sharing (e.g., DHCP), providing a name rather than an
+ address can simplify operations, assuming that the server's new
+ address is manually or automatically updated in the DNS; in this
+ case, there is no need to re-do parameter configuration, since the
+ name is still valid. Where fate sharing is supported (e.g., service
+ discovery protocols), a fresh address can be obtained by re-
+ initiating parameter configuration.
+
+ In providing the IP addresses for a set of servers, it is desirable
+ to distinguish which IP addresses belong to which servers. If a
+ server IP address is unreachable, this enables the host to try the IP
+ address of another server, rather than another IP address of the same
+ server, in case the server is down. This can be enabled by
+ distinguishing which addresses belong to the same server.
+
+3.4. Dual-Stack Issues
+
+ One use for learning a list of interchangeable server addresses is
+ for fault tolerance, in case one or more of the servers are
+ unresponsive. Hosts will typically try the addresses in turn, only
+ attempting to use the second and subsequent addresses in the list if
+
+
+
+Aboba, et al. Informational [Page 15]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ the first one fails to respond quickly enough. In such cases, having
+ the list sorted in order of expected likelihood of success will help
+ clients get results faster. For hosts that support both IPv4 and
+ IPv6, it is desirable to obtain both IPv4 and IPv6 server addresses
+ within a single list. Obtaining IPv4 and IPv6 addresses in separate
+ lists, without indicating which server(s) they correspond to,
+ requires the host to use a heuristic to merge the lists.
+
+ For example, assume there are two servers, A and B, each with one
+ IPv4 address and one IPv6 address. If the first address the host
+ should try is (say) the IPv6 address of server A, then the second
+ address the host should try, if the first one fails, would generally
+ be the IPv4 address of server B. This is because the failure of the
+ first address could be due to either server A being down, or some
+ problem with the host's IPv6 address, or a problem with connectivity
+ to server A. Trying the IPv4 address next is preferred since the
+ reachability of the IPv4 address is independent of all potential
+ failure causes.
+
+ If the list of IPv4 server addresses were obtained separately from
+ the list of IPv6 server addresses, a host trying to merge the lists
+ would not know which IPv4 addresses belonged to the same server as
+ the IPv6 address it just tried. This can be solved either by
+ explicitly distinguishing which addresses belong to which server or,
+ more simply, by configuring the host with a combined list of both
+ IPv4 and IPv6 addresses. Note that the same issue can arise with any
+ mechanism (e.g., DHCP, DNS, etc.) for obtaining server IP addresses.
+
+ Configuring a combined list of both IPv4 and IPv6 addresses gives the
+ configuration mechanism control over the ordering of addresses, as
+ compared with configuring a name and allowing the host resolver to
+ determine the address list ordering. See "Dynamic Host Configuration
+ Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues" [RFC4477] for more
+ discussion of dual-stack issues in the context of DHCP.
+
+3.5. Relationship between Per-Interface and Per-Host Configuration
+
+ Parameters that are configured or acquired on a per-interface basis
+ can affect behavior of the host as a whole. Where only a single
+ configuration can be applied to a host, the host may need to
+ prioritize the per-interface configuration information in some way
+ (e.g., most trusted to least trusted). If the host needs to merge
+ per-interface configuration to produce a host-wide configuration, it
+ may need to take the union of the per-host configuration parameters
+ and order them in some way (e.g., highest speed interface to lowest
+ speed interface). Which procedure is to be applied and how this is
+ accomplished may vary depending on the parameter being configured.
+ Examples include:
+
+
+
+Aboba, et al. Informational [Page 16]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ Boot service configuration
+
+ While boot service configuration can be provided on multiple
+ interfaces, a given host may be limited in the number of boot
+ loads that it can handle simultaneously. For example, a host not
+ supporting virtualization may only be capable of handling a single
+ boot load at a time, or a host capable of supporting N virtual
+ machines may only be capable of handling up to N simultaneous boot
+ loads. As a result, a host may need to select which boot load(s)
+ it will act on, out of those configured on a per-interface basis.
+ This requires that the host prioritize them (e.g., most to least
+ trusted).
+
+ Name service configuration
+
+ While name service configuration is provided on a per-interface
+ basis, name resolution configuration typically will affect
+ behavior of the host as a whole. For example, given the
+ configuration of DNS server addresses and searchlist parameters on
+ each interface, the host determines what sequence of name service
+ queries is to be sent on which interfaces.
+
+ Since the algorithms used to determine per-host behavior based on
+ per-interface configuration can affect interoperability, it is
+ important for these algorithms to be understood by implementers. We
+ therefore recommend that documents defining per-interface mechanisms
+ for acquiring per-host configuration (e.g., DHCP or IPv6 Router
+ Advertisement options) include guidance on how to deal with multiple
+ interfaces. This may include discussions of the following items:
+
+ 1. Merging. How are per-interface configurations combined to produce
+ a per-host configuration? Is a single configuration selected, or
+ is the union of the configurations taken?
+
+ 2. Prioritization. Are the per-interface configurations prioritized
+ as part of the merge process? If so, what are some of the
+ considerations to be taken into account in prioritization?
+
+4. Security Considerations
+
+ Secure IP configuration presents a number of challenges. In addition
+ to denial-of-service and man-in-the-middle attacks, attacks on
+ configuration mechanisms may target particular parameters. For
+ example, attackers may target DNS server configuration in order to
+ support subsequent phishing or pharming attacks such as those
+ described in "New trojan in mass DNS hijack" [DNSTrojan]. A number
+ of issues exist with various classes of parameters, as discussed in
+ Section 2.6, Section 4.2.7 of "IPv6 Neighbor Discovery (ND) Trust
+
+
+
+Aboba, et al. Informational [Page 17]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ Models and Threats" [RFC3756], Section 1.1 of "Authentication for
+ DHCP Messages" [RFC3118], and Section 23 of "Dynamic Host
+ Configuration Protocol for IPv6 (DHCPv6)" [RFC3315]. Given the
+ potential vulnerabilities, hosts often restrict support for DHCP
+ options to the minimum set required to provide basic TCP/IP
+ configuration.
+
+ Since boot configuration determines the boot image to be run by the
+ host, a successful attack on boot configuration could result in an
+ attacker gaining complete control over a host. As a result, it is
+ particularly important that boot configuration be secured.
+ Approaches to boot configuration security are described in
+ "Bootstrapping Clients using the Internet Small Computer System
+ Interface (iSCSI) Protocol" [RFC4173] and "Preboot Execution
+ Environment (PXE) Specification" [PXE].
+
+4.1. Configuration Authentication
+
+ The techniques available for securing Internet-layer configuration
+ are limited. While it is technically possible to perform a very
+ limited subset of IP networking operations without an IP address, the
+ capabilities are severely restricted. A host without an IP address
+ cannot receive conventional unicast IP packets, only IP packets sent
+ to the broadcast or a multicast address. Configuration of an IP
+ address enables the use of IP fragmentation; packets sent from the
+ unknown address cannot be reliably reassembled, since fragments from
+ multiple hosts using the unknown address might be reassembled into a
+ single IP packet. Without an IP address, it is not possible to take
+ advantage of security facilities such as IPsec, specified in
+ "Security Architecture for the Internet Protocol" [RFC4301] or
+ Transport Layer Security (TLS) [RFC5246]. As a result, configuration
+ security is typically implemented within the configuration protocols
+ themselves.
+
+ PPP [RFC1661] does not support secure negotiation within IPv4CP
+ [RFC1332] or IPv6CP [RFC5072], enabling an attacker with access to
+ the link to subvert the negotiation. In contrast, IKEv2 [RFC4306]
+ provides encryption, integrity, and replay protection for
+ configuration exchanges.
+
+ Where configuration packets are only expected to originate on
+ particular links or from particular hosts, filtering can help control
+ configuration spoofing. For example, a wireless access point usually
+ has no reason to forward broadcast DHCP DISCOVER packets to its
+ wireless clients, and usually should drop any DHCP OFFER packets
+ received from those wireless clients, since, generally speaking,
+ wireless clients should be requesting addresses from the network, not
+
+
+
+
+Aboba, et al. Informational [Page 18]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ offering them. To prevent spoofing, communication between the DHCP
+ relay and servers can be authenticated and integrity protected using
+ a mechanism such as IPsec.
+
+ Internet-layer secure configuration mechanisms include SEcure
+ Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address
+ autoconfiguration [RFC4862], or DHCP authentication for stateful
+ address configuration. DHCPv4 [RFC2131] initially did not include
+ support for security; this was added in "Authentication for DHCP
+ Messages" [RFC3118]. DHCPv6 [RFC3315] included security support.
+ However, DHCP authentication is not widely implemented for either
+ DHCPv4 or DHCPv6.
+
+ Higher-layer configuration can make use of a wider range of security
+ techniques. When DHCP authentication is supported, higher-layer
+ configuration parameters provided by DHCP can be secured. However,
+ even if a host does not support DHCPv6 authentication, higher-layer
+ configuration via Stateless DHCPv6 [RFC3736] can still be secured
+ with IPsec.
+
+ Possible exceptions can exist where security facilities are not
+ available until later in the boot process. It may be difficult to
+ secure boot configuration even once the Internet layer has been
+ configured, if security functionality is not available until after
+ boot configuration has been completed. For example, it is possible
+ that Kerberos, IPsec, or TLS will not be available until later in the
+ boot process; see "Bootstrapping Clients using the Internet Small
+ Computer System Interface (iSCSI) Protocol" [RFC4173] for discussion.
+
+ Where public key cryptography is used to authenticate and integrity-
+ protect configuration, hosts need to be configured with trust anchors
+ in order to validate received configuration messages. For a node
+ that visits multiple administrative domains, acquiring the required
+ trust anchors may be difficult.
+
+5. Informative References
+
+ [3GPP-24.008] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
+ specification; Core network protocols; Stage 3 (Release
+ 5)", June 2003.
+
+ [DNSTrojan] Goodin, D., "New trojan in mass DNS hijack", The
+ Register, December 5, 2008,
+ http://www.theregister.co.uk/2008/12/05/
+ new_dnschanger_hijacks/
+
+ [IEN116] J. Postel, "Internet Name Server", IEN 116, August
+ 1979, http://www.ietf.org/rfc/ien/ien116.txt
+
+
+
+Aboba, et al. Informational [Page 19]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ [IEEE-802.1X] Institute of Electrical and Electronics Engineers,
+ "Local and Metropolitan Area Networks: Port-Based
+ Network Access Control", IEEE Standard 802.1X-2004,
+ December 2004.
+
+ [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service
+ Discovery", Work in Progress, September 2008.
+
+ [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in
+ Progress, September 2008.
+
+ [PXE] Henry, M. and M. Johnston, "Preboot Execution
+ Environment (PXE) Specification", September 1999,
+ http://www.pix.net/software/pxeboot/archive/pxespec.pdf
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC1001] NetBIOS Working Group in the Defense Advanced Research
+ Projects Agency, Internet Activities Board, and End-
+ to-End Services Task Force, "Protocol standard for a
+ NetBIOS service on a TCP/UDP transport: Concepts and
+ methods", STD 19, RFC 1001, March 1987.
+
+ [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC
+ 1191, November 1990.
+
+ [RFC1332] McGregor, G., "The PPP Internet Protocol Control
+ Protocol (IPCP)", RFC 1332, May 1992.
+
+ [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
+ RFC 1350, July 1992.
+
+ [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
+ STD 51, RFC 1661, July 1994.
+
+ [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol
+ Extensions for Name Server Addresses", RFC 1877,
+ December 1995.
+
+ [RFC1958] Carpenter, B., Ed., "Architectural Principles of the
+ Internet", RFC 1958, June 1996.
+
+ [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
+ Discovery for IP version 6", RFC 1981, August 1996.
+
+ [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
+ 2131, March 1997.
+
+
+
+Aboba, et al. Informational [Page 20]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
+ "Service Location Protocol, Version 2", RFC 2608, June
+ 1999.
+
+ [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
+ 2923, September 2000.
+
+ [RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication
+ for DHCP Messages", RFC 3118, June 2001.
+
+ [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T.,
+ Perkins, C., and M. Carney, "Dynamic Host Configuration
+ Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+ [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
+ 3344, August 2002.
+
+ [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration
+ Protocol (DHCP) Domain Search Option", RFC 3397,
+ November 2002.
+
+ [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic
+ Host Configuration Protocol (DHCPv4) Configuration of
+ IPsec Tunnel Mode", RFC 3456, January 2003.
+
+ [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
+ Beame, C., Eisler, M., and D. Noveck, "Network File
+ System (NFS) version 4 Protocol", RFC 3530, April 2003.
+
+ [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
+ and E. Zeidner, "Internet Small Computer Systems
+ Interface (iSCSI)", RFC 3720, April 2004.
+
+ [RFC3736] Droms, R., "Stateless Dynamic Host Configuration
+ Protocol (DHCP) Service for IPv6", RFC 3736, April
+ 2004.
+
+ [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
+ H. Levkowetz, Ed., "Extensible Authentication Protocol
+ (EAP)", RFC 3748, June 2004.
+
+ [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
+ Neighbor Discovery (ND) Trust Models and Threats", RFC
+ 3756, May 2004.
+
+ [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
+ Support in IPv6", RFC 3775, June 2004.
+
+
+
+
+Aboba, et al. Informational [Page 21]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ [RFC3818] Schryver, V., "IANA Considerations for the Point-to-
+ Point Protocol (PPP)", BCP 88, RFC 3818, June 2004.
+
+ [RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C.,
+ and W. Jerome, "Remote Service Discovery in the Service
+ Location Protocol (SLP) via DNS SRV", RFC 3832, July
+ 2004.
+
+ [RFC3898] Kalusivalingam, V., "Network Information Service (NIS)
+ Configuration Options for Dynamic Host Configuration
+ Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
+
+ [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
+ Configuration of IPv4 Link-Local Addresses", RFC 3927,
+ May 2005.
+
+ [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
+ "SEcure Neighbor Discovery (SEND)", RFC 3971, March
+ 2005.
+
+ [RFC3972] Aura, T., "Cryptographically Generated Addresses
+ (CGA)", RFC 3972, March 2005.
+
+ [RFC4171] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C.,
+ and J. Souza, "Internet Storage Name Service (iSNS)",
+ RFC 4171, September 2005.
+
+ [RFC4173] Sarkar, P., Missimer, D., and C. Sapuntzakis,
+ "Bootstrapping Clients using the Internet Small
+ Computer System Interface (iSCSI) Protocol", RFC 4173,
+ September 2005.
+
+ [RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic
+ Host Configuration Protocol (DHCP) Option for the
+ Internet Storage Name Service", RFC 4174, September
+ 2005.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
+ Protocol", RFC 4306, December 2005.
+
+ [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
+ Information Approaches", RFC 4339, February 2006.
+
+
+
+
+
+
+Aboba, et al. Informational [Page 22]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+ [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
+ Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack
+ Issues", RFC 4477, May 2006.
+
+ [RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host
+ Configuration Protocol (DHCP) Options for the Intel
+ Preboot eXecution Environment (PXE)", RFC 4578,
+ November 2006.
+
+ [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
+ Multicast Name Resolution (LLMNR)", RFC 4795, January
+ 2007.
+
+ [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path
+ MTU Discovery", RFC 4821, March 2007.
+
+ [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+ Address Autoconfiguration", RFC 4862, September 2007.
+
+ [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
+ Extensions for Stateless Address Autoconfiguration in
+ IPv6", RFC 4941, September 2007.
+
+ [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version
+ 6 over PPP", RFC 5072, September 2007.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.2", RFC 5246, August
+ 2008.
+
+ [STD3] Braden, R., Ed., "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122, October 1989.
+
+ Braden, R., Ed., "Requirements for Internet Hosts -
+ Application and Support", STD 3, RFC 1123, October
+ 1989.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Informational [Page 23]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+Appendix A. Acknowledgments
+
+ Elwyn Davies, Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola,
+ James Kempf, Ted Hardie, and Alfred Hoenes provided valuable input on
+ this document.
+
+Appendix B. IAB Members at the Time of This Writing
+
+ Loa Andersson
+ Gonzalo Camarillo
+ Stuart Cheshire
+ Russ Housley
+ Olaf Kolkman
+ Gregory Lebovitz
+ Barry Leiba
+ Kurtis Lindqvist
+ Andrew Malis
+ Danny McPherson
+ David Oran
+ Dave Thaler
+ Lixia Zhang
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Informational [Page 24]
+
+RFC 5505 Principles of Internet Host Configuration May 2009
+
+
+Authors' Addresses
+
+ Bernard Aboba
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ EMail: bernarda@microsoft.com
+
+
+ Dave Thaler
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ EMail: dthaler@microsoft.com
+
+
+ Loa Andersson
+ Ericsson AB
+
+ EMail: loa.andersson@ericsson.com
+
+
+ Stuart Cheshire
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino, CA 95014
+
+ EMail: cheshire@apple.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al. Informational [Page 25]
+