GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5505

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5505.txt · Last modified: 2009/05/18 23:32 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki