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

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