One document matched: draft-iab-ip-config-04.txt
Differences from draft-iab-ip-config-03.txt
Network Working Group B. Aboba
INTERNET-DRAFT D. Thaler
Category: Informational Microsoft Corporation
Expires: November 25, 2008 Loa Andersson
25 May 2008 Acreo AB
Internet Architecture Board
Principles of Internet Host Configuration
draft-iab-ip-config-04.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 November 25, 2008.
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.
IAB Informational [Page 1]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
Table of Contents
1. Introduction.............................................. 3
1.1 Terminology ........................................ 3
2. Principles ............................................... 6
2.1 Minimize Configuration ............................. 6
2.2 Less is More ....................................... 6
2.3 Diversity is Not a Benefit ......................... 7
2.4 Lower Layer Independence ........................... 8
2.5 Configuration is Not Access Control ................ 9
3. Additional Discussion .................................... 10
3.1 General Purpose Mechanisms ......................... 10
3.2 Service Discovery .................................. 10
4. Security Considerations .................................. 13
4.1 Configuration Authentication ....................... 13
5. IANA Considerations ...................................... 14
6. References ............................................... 14
6.1 Informative References ............................. 14
Acknowledgments .............................................. 17
Appendix A - IAB Members ..................................... 17
Authors' Addresses ........................................... 18
Full Copyright Statement ..................................... 18
Intellectual Property ........................................ 19
IAB Informational [Page 2]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
1. Introduction
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.
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 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.
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.
IAB Informational [Page 3]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
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
step, since this enables a host to fill in the source address
in the packets it sends, as well as to receive packets
destined to that address. As a result, the host can receive
unicast IP packets, rather than requiring that IP packets be
sent to the broadcast or multicast address. Configuration of
an IP address also enables the use of IP fragmentation, since
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).
Configuration of an IP address also enables use of Internet
layer security facilities such as IPsec specified in "Security
Architecture for the Internet Protocol" [RFC4301].
Subnet prefix(es)
Once a subnet prefix is configured, hosts with an IP address
can exchange unicast IP packets with on-link hosts.
Default gateway(s)
Once a default gateway is configured, hosts with an IP address
can send and receive unicast IP packets from off-link hosts,
assuming unobstructed connectivity.
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),
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 diskless
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
IAB Informational [Page 4]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
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.
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, Domain Name Service
(DNS), Windows Internet Name Service (WINS), Internet Storage
Name Service (iSNS) and Network Information Service (NIS)
servers, and the setting of name resolution parameters such as
the NetBIOS node type, the DNS domain and search list, 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.
IAB Informational [Page 5]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
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
Transmission Control Protocol (TCP) [RFC793] does not require
configuration of the Maximum Segment Size, but is able to compute an
appropriate value.
Some protocols support self-configuration mechanisms, such as
capability negotiation or 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 a wide range of devices, from embedded devices operating with
minimal footprint to supercomputers. 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 the Pre-boot Execution Environment (PXE), prior
to obtaining a boot image, the host is typically only able to
communicate using IP and the User Datagram Protocol (UDP). This is
one reason why Internet layer configuration mechanisms typically
depend only on IP and UDP. After obtaining the boot image, the host
IAB Informational [Page 6]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
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 may wish to minimize the code included within a
boot Read-Only Memory (ROM), availability of higher layer facilities
cannot be guaranteed during Internet layer configuration. In fact,
it cannot even be guaranteed that all Internet layer facilities will
be available. For example, IP fragmentation and reassembly may not
work reliably until a host has obtained an IP address.
2.3. Diversity is Not a Benefit
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 need to implement
all configuration mechanisms used on the link layers
they support. This increases the required
footprint, a burden for embedded devices.
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
IAB Informational [Page 7]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
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 potential for security vulnerabilities
in one of the mechanisms.
2.4. Lower Layer Independence
RFC 1958 [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,
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 - see Section 2.1).
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
IAB Informational [Page 8]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
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, in IPv6 where link
layer independent mechanisms such as "IPv6 Stateless Address
Autoconfiguration" [RFC4862] and DHCPv6 [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.
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 requirements of [RFC3748] Section 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 authorizaton 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.
IAB Informational [Page 9]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
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.
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. 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.
Given the number of Internet host configuration mechanisms that have
already been defined, there is no justification for hard coding of
service IP addresses or domain names. Taking into account the
problems resulting from the proliferation of these mechanisms, there
is no apparent 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 global
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. 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
IAB Informational [Page 10]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
Service Service Discovery (DNS-SD) [DNS-SD].
In Internet host configuration mechanisms such as DHCP, server
instances are considered equivalent. 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.
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-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] 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 many situations fate sharing is imperfect or
IAB Informational [Page 11]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
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, where service discovery is assisted by a DA, the
ability to discover services is dependent on whether the DA is
operational, even though the DA is typically not involved in the
delivery of the service. Since the DA's list of operational servers
may not be current, it is possible for the DA to provide clients with
service information that is out of date. For example, service
descriptions provided to the DA by servers might be included in
response to service discovery queries sent by clients even after the
servers were no longer operational. Similarly, recently introduced
servers might not yet have registered themselves with the DA. Thus,
fate sharing can be imperfect.
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 a well-known anycast
address for each service.
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. However, 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.
IAB Informational [Page 12]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
In obtaining 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.
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, since transmission layer security protocols such as
IPsec [RFC4301] or Transport Layer Security (TLS) [RFC4346] cannot be
used until an IP address has been configured. 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
IAB Informational [Page 13]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
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
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
IAB Informational [Page 14]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
specification; Core network protocols; Stage 3 (Release 5)",
June 2003.
[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
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[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.
[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.
[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.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
IAB Informational [Page 15]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
[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.
[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.
[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.
[RFC4173] Sarkar, P., Missimer, D. and C. Sapuntzakis, "Bootstrapping
Clients using the iSCSI Protocol", RFC 4173, September 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
IAB Informational [Page 16]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
[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.
[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.
[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.
Acknowledgments
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
Olaf Kolkman
Barry Leiba
Kurtis Lindqvist
Danny McPherson
David Oran
Eric Rescorla
Dave Thaler
Lixia Zhang
IAB Informational [Page 17]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
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
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.
IAB Informational [Page 18]
INTERNET-DRAFT Internet Host Configuration 25 May 2008
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.
IAB Informational [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 07:14:02 |