draft-iab-ip-config-03.txt   draft-iab-ip-config-04.txt 
Network Working Group B. Aboba Network Working Group B. Aboba
INTERNET-DRAFT D. Thaler INTERNET-DRAFT D. Thaler
Category: Informational Microsoft Corporation Category: Informational Microsoft Corporation
Expires: September 20, 2008 Loa Andersson Expires: November 25, 2008 Loa Andersson
20 March 2008 Acreo AB 25 May 2008 Acreo AB
Internet Architecture Board Internet Architecture Board
Principles of Internet Host Configuration Principles of Internet Host Configuration
draft-iab-ip-config-03.txt draft-iab-ip-config-04.txt
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 20, 2008. This Internet-Draft will expire on November 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes principles of Internet host configuration. This document describes principles of Internet host configuration.
It covers issues relating to configuration of Internet layer It covers issues relating to configuration of Internet layer
parameters, as well as parameters affecting higher layer protocols. parameters, as well as parameters affecting higher layer protocols.
skipping to change at page 5, line 24 skipping to change at page 5, line 24
Name Service Configuration Name Service Configuration
The configuration required for the host to resolve names. The configuration required for the host to resolve names.
This includes configuration of the addresses of name This includes configuration of the addresses of name
resolution servers, including IEN 116, Domain Name Service resolution servers, including IEN 116, Domain Name Service
(DNS), Windows Internet Name Service (WINS), Internet Storage (DNS), Windows Internet Name Service (WINS), Internet Storage
Name Service (iSNS) and Network Information Service (NIS) Name Service (iSNS) and Network Information Service (NIS)
servers, and the setting of name resolution parameters such as servers, and the setting of name resolution parameters such as
the NetBIOS node type, the DNS domain and search list, etc. the NetBIOS node type, the DNS domain and search list, etc.
It may also include the transmission or setting of the host's It may also include the transmission or setting of the host's
own name. Note that Link local name resolution services (such own name. Note that Link local name resolution services (such
as NetBIOS [RFC1001], LLMNR [RFC4795] and mDNS [mDNS]) as NetBIOS [RFC1001], Link Local Multicast Name Resolution
typically do not require configuration. (LLMNR) [RFC4795] and multicast DNS (mDNS) [mDNS]) typically
do not require configuration.
Once the host has completed name service configuration, it is Once the host has completed name service configuration, it is
capable of resolving names using name resolution protocols capable of resolving names using name resolution protocols
that require configuration. This not only allows the host to that require configuration. This not only allows the host to
communicate with off-link hosts whose IP address is not known, communicate with off-link hosts whose IP address is not known,
but to the extent that name services requiring configuration but to the extent that name services requiring configuration
are utilized for service discovery, this also enables the host are utilized for service discovery, this also enables the host
to discover services available on the network or elsewhere. to discover services available on the network or elsewhere.
Time Service Configuration Time Service Configuration
skipping to change at page 7, line 10 skipping to change at page 7, line 10
to obtaining a boot image, the host is typically only able to to obtaining a boot image, the host is typically only able to
communicate using IP and the User Datagram Protocol (UDP). This is communicate using IP and the User Datagram Protocol (UDP). This is
one reason why Internet layer configuration mechanisms typically one reason why Internet layer configuration mechanisms typically
depend only on IP and UDP. After obtaining the boot image, the host 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 will have the full facilities of TCP/IP available to it, including
support for reliable transport protocols, IPsec, etc. support for reliable transport protocols, IPsec, etc.
In order to reduce complexity, it is desirable for Internet layer In order to reduce complexity, it is desirable for Internet layer
configuration mechanisms to avoid dependencies on higher layers. configuration mechanisms to avoid dependencies on higher layers.
Since embedded hosts may wish to minimize the code included within a Since embedded hosts may wish to minimize the code included within a
boot ROM, availability of higher layer facilities cannot be boot Read-Only Memory (ROM), availability of higher layer facilities
guaranteed during Internet layer configuration. In fact, it cannot cannot be guaranteed during Internet layer configuration. In fact,
even be guaranteed that all Internet layer facilities will be it cannot even be guaranteed that all Internet layer facilities will
available. For example, IP fragmentation and reassembly may not work be available. For example, IP fragmentation and reassembly may not
reliably until a host has obtained an IP address. work reliably until a host has obtained an IP address.
2.3. Diversity is Not a Benefit 2.3. Diversity is Not a Benefit
The number of host configuration mechanisms should be minimized. The number of host configuration mechanisms should be minimized.
Diversity in Internet host configuration mechanisms presents several Diversity in Internet host configuration mechanisms presents several
problems: problems:
Interoperability As configuration diversity increases, it becomes Interoperability As configuration diversity increases, it becomes
likely that a host will not support the likely that a host will not support the
configuration mechanism(s) available on the network configuration mechanism(s) available on the network
skipping to change at page 8, line 25 skipping to change at page 8, line 25
increases the potential for security vulnerabilities increases the potential for security vulnerabilities
in one of the mechanisms. in one of the mechanisms.
2.4. Lower Layer Independence 2.4. Lower Layer Independence
RFC 1958 [RFC1958] states, "Modularity is good. If you can keep RFC 1958 [RFC1958] states, "Modularity is good. If you can keep
things separate, do so." things separate, do so."
It is becoming increasingly common for hosts to support multiple It is becoming increasingly common for hosts to support multiple
network access mechanisms, including dialup, wireless and wired local network access mechanisms, including dialup, wireless and wired local
area networks, wireless metropolitan and wide area networks, etc. As area networks, wireless metropolitan and wide area networks, etc.
a result, it is desirable for hosts to be able to configure The proliferation of network access mechanisms makes it desirable for
themselves on multiple networks without adding configuration code hosts to be able to configure themselves on multiple networks without
specific to a new link layer. adding configuration code specific to a new link layer.
As a result, it is highly desirable for Internet host configuration As a result, it is highly desirable for Internet host configuration
mechanisms to be independent of the underlying lower layer. That is, mechanisms to be independent of the underlying lower layer. That is,
the link layer protocol (whether it be a physical link, or a virtual the link layer protocol (whether it be a physical link, or a virtual
tunnel link) should only be explicitly aware of link-layer parameters tunnel link) should only be explicitly aware of link-layer parameters
(although it may configure link-layer parameters - see Section 2.1). (although it may configure link-layer parameters - see Section 2.1).
Introduction of lower layer dependencies increases the likelihood of Introduction of lower layer dependencies increases the likelihood of
interoperability problems and adds to the number of Internet layer interoperability problems and adds to the number of Internet layer
configuration mechanisms that hosts need to implement. configuration mechanisms that hosts need to implement.
Lower layer dependencies can be best avoided by keeping Internet host Lower layer dependencies can be best avoided by keeping Internet host
configuration above the link layer, thereby enabling configuration to configuration above the link layer, thereby enabling configuration to
be handled for any link layer that supports IP. In order to provide be handled for any link layer that supports IP. In order to provide
media independence, Internet host configuration mechanisms should be media independence, Internet host configuration mechanisms should be
link-layer protocol independent. link-layer protocol independent.
While there are examples of IP address assignment within the link While there are examples of IP address assignment within the link
layer (such as in the Point-to-Point Protocol (PPP) IPv4CP layer (such as in the Point-to-Point Protocol (PPP) IPv4CP [RFC1332]
[RFC1332]), the disadvantages of this approach have now become and "Mobile radio interface Layer 3 specification; Core network
apparent. The main disadvantages include the extra complexity of protocols; Stage 3 (Release 5)" [3GPP-24.008]), the disadvantages of
implementing different mechanisms on different link layers, and the this approach have now become apparent. This includes the extra
difficulty in adding new parameters which would require defining a complexity of implementing different mechanisms on different link
mechanism in each link layer protocol. 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 For example, PPP IPv4CP and "Internet Protocol Control Protocol
(IPCP) Extensions for Name Service Configuration" [RFC1877] were (IPCP) Extensions for Name Service Configuration" [RFC1877] were
developed at a time when the Dynamic Host Configuration Protocol developed at a time when the Dynamic Host Configuration Protocol
(DHCP) [RFC2131] had not yet been widely implemented on access (DHCP) [RFC2131] had not yet been widely implemented on access
devices or in service provider networks. However, in IPv6 where link devices or in service provider networks. However, in IPv6 where link
layer independent mechanisms such as "IPv6 Stateless Address layer independent mechanisms such as "IPv6 Stateless Address
Autoconfiguration" [RFC4862] and DHCPv6 [RFC3736] are available, PPP Autoconfiguration" [RFC4862] and DHCPv6 [RFC3736] are available, PPP
IPv6CP [RFC5072] instead simply configures an Interface-Identifier IPv6CP [RFC5072] instead simply configures an Interface-Identifier
which is similar to a MAC address. This enables PPP IPv6CP to avoid which is similar to a MAC address. This enables PPP IPv6CP to avoid
having to duplicate DHCPv6 functionality. duplicating DHCPv6 functionality.
In contrast, Internet Key Exchange Version 2 (IKEv2) [RFC4306] In contrast, Internet Key Exchange Version 2 (IKEv2) [RFC4306]
utilizes the same approach as PPP IPv4CP by defining a Configuration utilizes the same approach as PPP IPv4CP by defining a Configuration
Payload for Internet host configuration for both IPv4 and IPv6. As Payload for Internet host configuration for both IPv4 and IPv6. As
pointed out in "Dynamic Host Configuration Protocol (DHCPv4) pointed out in "Dynamic Host Configuration Protocol (DHCPv4)
Configuration of IPsec Tunnel Mode" [RFC3456], leveraging DHCP has Configuration of IPsec Tunnel Mode" [RFC3456], leveraging DHCP has
advantages in terms of address management integration, address pool advantages in terms of address management integration, address pool
management, reconfiguration and fail-over. On the other hand, the management, reconfiguration and fail-over. On the other hand, the
IKEv2 approach reduces the number of exchanges. IKEv2 approach reduces the number of exchanges.
skipping to change at page 11, line 27 skipping to change at page 11, line 28
For the service discovery problem (i.e., where the criteria varies on For the service discovery problem (i.e., where the criteria varies on
a per-request basis, even from the same host), protocols should a per-request basis, even from the same host), protocols should
either be self-discovering (if fate sharing is critical), or use either be self-discovering (if fate sharing is critical), or use
general purpose service discovery mechanisms. general purpose service discovery mechanisms.
In order to avoid a dependency on multicast routing, it is necessary 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 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 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 may not be available on the local link, service discovery beyond the
local link is typically dependent on a parameter configuration local link is typically dependent on a mechanism for configuring the
mechanism. As a result, service discovery protocols can typically DA address or name. As a result, service discovery protocols can
not be relied upon for obtaining basic Internet layer configuration. typically not be relied upon for obtaining basic Internet layer
However, they can be used to obtain higher-layer configuration configuration, although they can be used to obtain higher-layer
parameters. configuration parameters.
3.2.1. Fate Sharing 3.2.1. Fate Sharing
If a server (or set of servers) is needed to get a set of If a server (or set of servers) is needed to get a set of
configuration parameters, "fate sharing" ([RFC1958] Section 2.3) is configuration parameters, "fate sharing" ([RFC1958] Section 2.3) is
preserved if the servers are ones without which the parameters could preserved if the servers are ones without which the parameters could
not be used, even if they were obtained via other means. The not be used, even if they were obtained via other means. The
possibility of incorrect information being configured is minimized if possibility of incorrect information being configured is minimized if
there is only one machine which is authoritative for the information there is only one machine which is authoritative for the information
(i.e., there is no need to keep multiple authoritative servers in (i.e., there is no need to keep multiple authoritative servers in
skipping to change at page 12, line 40 skipping to change at page 12, line 42
3.2.2. Discovering Names vs. Addresses 3.2.2. Discovering Names vs. Addresses
In discovering servers other than name resolution servers, it is In discovering servers other than name resolution servers, it is
possible to either discover the IP addresses of the server(s), or to 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. discover names, each of which may resolve to a list of addresses.
It is typically more efficient to obtain the list of addresses It is typically more efficient to obtain the list of addresses
directly, since this avoids the extra name resolution steps and directly, since this avoids the extra name resolution steps and
accompanying latency. However, where servers are mobile, the name to accompanying latency. However, where servers are mobile, the name to
address binding may change, so that the initially discovered address binding may change, requiring a fresh set of addresses to be
addresses can become stale. In such a situation, if the discovery obtained. Where the configuration mechanism does not support fate
mechanism supports fate sharing then a fresh set of addresses can be sharing (e.g. DHCP), providing a name rather than an address can
obtained by re-initiating discovery. If there is no fate sharing simplify operations, assuming that the server's new address is
(e.g. the server address has been provided via DNS, but the server manually or automatically updated in the DNS; in this case there is
has renumbered), but the server to address binding is dynamically no need to re-do parameter configuration, since the name is still
updated, then obtaining a list of names will be more robust. valid. Where fate sharing is supported (e.g. service discovery
protocols), a fresh address can be obtained by re-initiating
parameter configuration.
In obtaining the IP addresses for a set of servers, it is desirable In obtaining the IP addresses for a set of servers, it is desirable
to distinguish which IP addresses belong to which servers. If a to distinguish which IP addresses belong to which servers. If a
server IP address is unreachable, this enables the host to try the IP 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 address of another server, rather than another IP address of the same
server, in case the server is down. This can be enabled by server, in case the server is down. This can be enabled by
distinguishing which addresses belong to the same server. distinguishing which addresses belong to the same server.
4. Security Considerations 4. Security Considerations
skipping to change at page 14, line 10 skipping to change at page 14, line 14
Access Server (NAS) acts as a DHCP relay or server, protection can be Access Server (NAS) acts as a DHCP relay or server, protection can be
provided against rogue DHCP servers, provided that the NAS filters provided against rogue DHCP servers, provided that the NAS filters
incoming DHCP packets from unauthorized sources. However, explicit incoming DHCP packets from unauthorized sources. However, explicit
dependencies on lower layer security mechanisms are limited by the dependencies on lower layer security mechanisms are limited by the
"lower layer independence" principle (see Section 2.4). "lower layer independence" principle (see Section 2.4).
Internet layer secure configuration mechanisms include SEcure Internet layer secure configuration mechanisms include SEcure
Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address Neighbor Discovery (SEND) [RFC3971] for IPv6 stateless address
autoconfiguration [RFC4862], or DHCP authentication for stateful autoconfiguration [RFC4862], or DHCP authentication for stateful
address configuration. DHCPv4 [RFC2131] initially did not include address configuration. DHCPv4 [RFC2131] initially did not include
support for security; this was added in [RFC3118]. DHCPv6 [RFC3315] support for security; this was added in "Authentication for DHCP
included security support. However, DHCP authentication is not Messages" [RFC3118]. DHCPv6 [RFC3315] included security support.
widely implemented for either DHCPv4 or DHCPv6. However, DHCP authentication is not widely implemented for either
DHCPv4 or DHCPv6.
Higher layer configuration can make use of a wider range of security Higher layer configuration can make use of a wider range of security
techniques. When DHCP authentication is supported, higher-layer techniques. When DHCP authentication is supported, higher-layer
configuration parameters provided by DHCP can be secured. However, configuration parameters provided by DHCP can be secured. However,
even if a host does not support DHCPv6 authentication, higher-layer even if a host does not support DHCPv6 authentication, higher-layer
configuration via Stateless DHCPv6 [RFC3736] can still be secured configuration via Stateless DHCPv6 [RFC3736] can still be secured
with IPsec. with IPsec.
Possible exceptions can exist where security facilities are not Possible exceptions can exist where security facilities are not
available until later in the boot process. It may be difficult to available until later in the boot process. It may be difficult to
secure boot configuration even once the Internet layer has been secure boot configuration even once the Internet layer has been
configured, if security functionality is not available until after configured, if security functionality is not available until after
boot configuration has been completed. For example, it is possible boot configuration has been completed. For example, it is possible
that Kerberos, IPsec or TLS will not be available until later in the that Kerberos, IPsec or TLS will not be available until later in the
boot process; see [RFC4173] for discussion. 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 Where public key cryptography is used to authenticate and integrity
protect configuration, hosts need to be configured with trust anchors protect configuration, hosts need to be configured with trust anchors
in order to validate received configuration messages. For a node in order to validate received configuration messages. For a node
that visits multiple administrative domains, acquiring the required that visits multiple administrative domains, acquiring the required
trust anchors may be difficult. This is left as an area for future trust anchors may be difficult. This is left as an area for future
work. work.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. References 6. References
6.1. Informative 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.
[DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery", [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery",
Internet-Draft (work in progress), draft-cheshire-dnsext-dns- Internet-Draft (work in progress), draft-cheshire-dnsext-dns-
sd-04.txt, August 2006. sd-04.txt, August 2006.
[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005. [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005.
http://files.multicastdns.org/draft-cheshire-dnsext- http://files.multicastdns.org/draft-cheshire-dnsext-
multicastdns.txt multicastdns.txt
[PXE] Henry, M. and M. Johnston, "Preboot Execution Environment [PXE] Henry, M. and M. Johnston, "Preboot Execution Environment
(PXE) Specification", September 1999, (PXE) Specification", September 1999,
 End of changes. 13 change blocks. 
38 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/