Network Working Group                                           B. Aboba
INTERNET-DRAFT                                                 D. Thaler
Category: Informational                            Microsoft Corporation                                    Loa Andersson
Expires: January March 3, 2009                                   Loa Andersson
3 July                                   Stuart Cheshire
26 August 2008                                                     Acreo AB                               Internet Architecture Board

               Principles of Internet Host Configuration
                       draft-iab-ip-config-05.txt
                       draft-iab-ip-config-06.txt

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January March 3, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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.

   Table of Contents

1.  Introduction..............................................    3
      1.1 Terminology ........................................    3
      1.2 Internet Host Configuration ........................    4
2.  Principles ...............................................    6
      2.1 Minimize Configuration .............................    6
      2.2 Less is More .......................................    6    7
      2.3 Minimize Diversity .................................    7    8
      2.4 Lower Layer Independence ...........................    8    9
      2.5 Configuration is Not Access Control ................   10
3.  Additional Discussion ....................................   10   11
      3.1 Reliance on General Purpose Mechanisms .............   10   11
      3.2 Relationship between IP Configuration and
          Service Discovery ..................................   11
4.  Security Considerations ..................................   14   15
      4.1 Configuration Authentication .......................   14   16
5.  IANA Considerations ......................................   15   17
6.  References ...............................................   15   17
      6.1 Informative References .............................   16   17
Acknowledgments ..............................................   19   21
Appendix A - IAB Members .....................................   19   21
Authors' Addresses ...........................................   19   21
Full Copyright Statement .....................................   20   22
Intellectual Property ........................................   20   22

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 What protocol layers and general approaches are most appropriate
        for configuration of various parameters.

      o The relationship between parameter configuration and service
        discovery.

      o The relationship between network access authentication and host
        configuration.

      o The desirability of avoiding parameter configuration or
        supporting self-configuration.

      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 specified in
   "Privacy Extensions for Stateless Address Autoconfiguration in IPv6"
   [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), 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.

   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.

1.2.  Internet Host Configuration

   Internet layer configuration is defined as the configuration required
   to support the operation of the Internet layer.  This includes 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 an important a vital step,
              since this enables a host to fill in 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 in of an IP packet, these IP addresses
              indicate the packets it sends, as well sender of the packet; used as to receive
              packets destined to that address.  As a result, the host
              can receive destination
              address of a unicast IP packets, rather than requiring that packet, these IP packets be sent to addresses
              indicate the broadcast or multicast address.
              Configuration intended receiver.

              The only common example of IP-based protocols operating
              without an IP address also enables involves address configuration, such
              as the use of IP
              fragmentation.  Packets sent from DHCPv4 [RFC2131] to obtain an address.  In
              this case, by definition, DHCPv4 is operating before the unknown address
              cannot be reliably reassembled, since fragments from
              multiple hosts using
              client has an IPv4 address, so the unknown address might be
              reassembled into a single IP packet.  Configuration DHCP protocol designers
              had the choice of either using IP without an IP address also enables use address,
              or not using IP at all.  The benefits of Internet layer security
              facilities such as IPsec specified 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 "Security
              Architecture this constrained
              mode.  Use of IP for purposes other than address
              configuration can safely assume that the Internet Protocol" [RFC4301]. host will have
              one or more IP addresses, which may be self-configured
              link-local addresses, or other addresses configured via
              DHCP or other means.

   Subnet prefix(es)
              Once a subnet prefix is configured, 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, hosts with an IP
              address can send unicast IP packets from to that gateway for
              forwarding to off-link hosts,
              assuming unobstructed connectivity. 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.

   Other 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)).

   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) [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. Internet layer configuration.

   Other 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)).

   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, 116 [IEN116], Domain
              Name Service (DNS), Windows Internet Name Service (WINS),
              Internet Storage Name Service (iSNS) [RFC4171][RFC4174]
              and Network Information Service (NIS) servers, servers [RFC3898],
              and the setting of name resolution parameters such as the
              NetBIOS node type, the DNS domain and search list, list
              [RFC3397], 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 address is not known, but to the extent that name
              services requiring configuration are utilized for service
              discovery, this also enables the host to discover services
              available on the network or elsewhere.

   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.

   Other service configuration
              This can include discovery of additional servers and
              devices, such as printers, Session Initiation Protocol
              (SIP) proxies, etc.

2.  Principles

   This section describes basic principles of Internet host
   configuration.

2.1.  Minimize Configuration

   Anything that can be configured can be misconfigured.  "Architectural
   Principles of the Internet" [RFC1958] Section 3.8 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].

   Some

   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 support self-configuration mechanisms, can reduce the risk
   of human error by making these parameters self-configuring, such as
   by using capability negotiation within the protocol, or by 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.  RFC 1958
   [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 more types of devices, it is important
   to minimize the footprint requirement.  For example, Internet hosts
   span IP-based
   protocols are used on a wide range of devices,  from embedded supercomputers
   to small low-cost devices running "embedded" operating with
   minimal footprint to supercomputers. systems.
   Since 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 pre-boot 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.  In  Many hosts do not have enough space in this ROM
   for even a simple implementation of TCP, so in the Pre-boot Execution
   Environment (PXE), prior
   to (PXE) the task of obtaining a boot image, the host is typically only able image has to
   communicate be
   performed using IP and the User Datagram Protocol (UDP). 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 hosts devices may wish to minimize the be severely constrained on how much code included
   they can fit within their ROM, designing a
   boot Read-Only Memory (ROM), configuration mechanism in
   such a way that it requires the availability of higher layer
   facilities
   cannot be guaranteed during Internet layer configuration. 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 fragmentation and reassembly in a host's boot ROM may not
   work reliably until a host has obtained an implement IP address. 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          In order to interoperate, hosts          For maximum interoperability, a host would need to
                      implement all configuration mechanisms used on all
                      the link layers they support. it supports.  This increases the
                      required footprint, a burden for embedded devices.
                      It also leads to lower quality, since testing
                      resources (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 configuration(s) 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 potential
                      benefit.

2.4.  Lower Layer Independence

   RFC 1958

   "Architectural Principles of the Internet" [RFC1958] states,
   "Modularity is good. If you can keep things separate, do so."

   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 a 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 only be explicitly aware of link-layer
   parameters (although it may configure link-layer parameters). them).  Introduction of lower
   layer dependencies increases the likelihood of interoperability
   problems and adds to the number of 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 IP address assignment within the link
   layer (such as in the Point-to-Point Protocol (PPP) IPv4CP [RFC1332]
   and  "Mobile radio interface Layer 3 specification; Core network
   protocols; Stage 3 (Release 5)" [3GPP-24.008]), the disadvantages of
   this approach have now become apparent.  This includes the extra
   complexity of implementing different mechanisms on different link
   layers, and the difficulty in adding new parameters which would
   require defining a mechanism in each link layer protocol.

   For example, PPP IPv4CP and "Internet Protocol Control Protocol
   (IPCP) Extensions for Name Service Configuration" [RFC1877] were
   developed at a time when the Dynamic Host Configuration Protocol
   (DHCP) [RFC2131] had not yet been widely implemented on access
   devices or in service provider networks.  However, the world has
   changed since 1995, and if we were designing IPv4CP today, it would
   probably make use of DHCP instead of duplicating that functionality.
   Indeed, in IPv6 where link layer independent mechanisms such as "IPv6
   Stateless Address Autoconfiguration" [RFC4862] and DHCPv6 "Stateless Dynamic
   Host Configuration Protocol (DHCP) Service for IPv6" [RFC3736] are
   available, PPP IPv6CP [RFC5072] instead simply configures an
   Interface-Identifier which is similar to a MAC address.  This enables
   PPP IPv6CP to avoid duplicating DHCPv6 functionality.  The design of
   IPv4CP was appropriate in 1995, but should not be taken as an example
   that new link layer technologies should emulate.

   In contrast, 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.  As
   pointed out in "Dynamic Host Configuration Protocol (DHCPv4)
   Configuration of IPsec Tunnel Mode" [RFC3456], leveraging DHCP has
   advantages in terms of address management integration, address pool
   management, reconfiguration and fail-over.  On the other hand, the
   IKEv2 approach reduces the number of exchanges.

   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 desire "Privacy Extensions for Stateless
   Address Autoconfiguration in IPv6" [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) [RFC3748] may be run over any link satisfying the its
   requirements of (see [RFC3748] Section 3.1, 3.1), many link layers do not
   support EAP and therefore Internet layer configuration mechanisms
   with EAP dependencies would not be usable on all links that support
   IP.

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
   achieve this better using technologies like Port Based Network Access
   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 availability of existing general-purpose
   configuration mechanisms, there is no apparent we see little need for the 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.3), 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 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.

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 the
   Service Location Protocol Version 2 (SLPv2) [RFC2608] or Domain Name
   Service 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 equivalent. 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 it 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(s) in the local
   administrative domain contain the authoritative set of information.

   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
   general purpose service discovery mechanisms.

   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" ([RFC1958] ([RFC1958], Section 2.3) is
   preserved if the servers are ones without which the parameters could
   not be used, even if they were obtained via other means.  The
   possibility of incorrect information being configured is minimized if
   there is only one machine which 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 a number of situations fate sharing may be unavailable.
   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 that it is possible for
   the DA to 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.

   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, or do not
   discover new configuration information automatically.  As a result,
   there is no guarantee that configuration information will be current.

   "IPv6 Host configuration of DNS Server Information Approaches"
   [RFC4339] Section 3.3 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.2.2.  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.2.3.  Dual Stack Issues

   One use for learning a list of interchangeable server addresses is to enable a host
   to
   for fault tolerance, in case one or more of the servers are
   unresponsive.  Hosts will typically try them sequentially until the addresses in turn, only
   attempting to use the second and subsequent addresses in the list if
   the first one succeeds. fails to respond quickly enough.  In such cases, it is
   best for having
   the list to be ordered so that subsequent entries are most
   likely to succeed, assuming that attempts to connect to previous
   addresses have failed. 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 either be due to server A being down, or due to
   some problem with the host's IPv6 address.  Trying the IPv4 address
   next is preferred since the reachability of the IPv4 address is
   independent of both potential failure causes.

   If the list of IPv4 server addresses were obtained separate 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 also
   provides for more predictable 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 "DHCP Dual-Stack Issues"
   [RFC4477] for more discussion of dual-
   stack dual-stack issues in the context of
   DHCP.

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.  A number of issues
   exist with various classes of parameters, as discussed in Section
   2.6, "IPv6 Neighbor Discovery (ND) Trust Models and Threats"
   [RFC3756] Section 4.2.7, "Authentication for DHCP Messages" [RFC3118]
   Section 1.1, and "Dynamic Host Configuration Protocol for IPv6
   (DHCPv6)" [RFC3315] Section 23.  Given the potential vulnerabilities
   resulting from implementation of these options, it is currently
   common for hosts to 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, 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
   can only receive IP packets sent to the broadcast or multicast
   address.  Configuration of an IP address enables the use of IP
   fragmentation; packets sent from the unknown address cannot be
   reliably reassembled, since transmission layer 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 protocols facilities such as
   IPsec [RFC4301] IPsec, specified in "Security
   Architecture for the Internet Protocol" [RFC4301], or Transport Layer
   Security (TLS) [RFC4346] cannot be
   used until an IP address has been configured. [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.

   In situations where link layer security is provided, and the Network
   Access Server (NAS) acts as a DHCP relay or server, protection can be
   provided against rogue DHCP servers, provided that the NAS filters
   incoming DHCP packets from unauthorized sources.  However, explicit
   dependencies on lower layer security mechanisms are limited by the
   "lower layer independence" principle (see Section 2.4).

   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 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.  This is left as an area for future
   work.

5.  IANA Considerations

   This document has no actions for IANA.

6.  References

6.1.  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.

[IEN116]  J. Postel, "Internet Name Server", IEN 116, August 1979,
          http://www.ietf.org/rfc/ien/ien116.txt

[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",
          Internet-Draft (work in progress), draft-cheshire-dnsext-dns-
          sd-04.txt, August 2006.

[mDNS]    Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005.
          http://files.multicastdns.org/draft-cheshire-dnsext-
          multicastdns.txt

[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", 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., "PPP Internet Control Protocol", RFC 1332,
          Merit, May 1992.

[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC
          1350, July 1992.

[RFC1661] Simpson, W., "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., "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.

[RFC2608] Guttman, E., et al., "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. and W. Arbaugh, "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., "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, "Extensible Authentication Protocol (EAP)", RFC
          3748, June 2004.

[RFC3756] Nikander, P., 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.

[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., "Networking Information Service (NIS)
          Configuration Options for Dynamic Host Configuration Protocol
          for IPv6 (DHCPv6)", RFC 3898, October 2004.

[RFC3971] Arkko, J., Kempf, J., Sommerfeld, B., 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 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., "Internet Key Exchange (IKEv2) Protocol", RFC
          4306, December 2005.

[RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information
          Approaches", RFC 4339, February 2006.

[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
          (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[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, "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., 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., "Requirements for Internet Hosts -- Communication
          Layers", STD 3, RFC 1122, and "Requirements for Internet Hosts
          -- Application and Support", STD 3, RFC 1123, October 1989.

Acknowledgments

   Elwyn Davies, Bob Hinden, Pasi Eronen, Jari Arkko, Pekka Savola and
   James Kempf provided valuable input on this document.

Appendix A - IAB Members at the time of this writing

   Loa Andersson
   Leslie Daigle
   Elwyn Davies
   Kevin Fall
   Gonzalo Camarillo
   Stuart Cheshire
   Olaf Kolkman
   Gregory Lebovitz
   Barry Leiba
   Kurtis Lindqvist
   Andrew Malis
   Danny McPherson
   David Oran
   Eric Rescorla
   Dave Thaler
   Lixia Zhang

Authors' Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   EMail: bernarda@microsoft.com
   Phone: +1 425 706 6605
   Fax:   +1 425 936 7329

   Dave Thaler
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   EMail: dthaler@microsoft.com

   Loa Andersson
   Acreo AB

   EMail: loa@pi.se

   Stuart Cheshire
   Apple Computer, Inc.
   1 Infinite Loop
   Cupertino, CA 95014

   EMail: rfc [at] stuartcheshire [dot] org

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.