One document matched: draft-aboba-ip-config-00.txt
Network Working Group B. Aboba
INTERNET-DRAFT D. Thaler
Category: Informational Microsoft Corporation
<draft-aboba-ip-config-00.txt>
24 February 2007
Principles of Internet Host Configuration
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes basic principles of Internet host
configuration. It covers issues relating to configuration of
parameters that affect the Internet layer, as well as parameters
affecting higher layer protocols.
Aboba & Thaler Informational [Page 1]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
Table of Contents
1. Introduction.............................................. 3
1.1 Terminology ........................................ 3
2. Principles ............................................... 5
2.1 Minimize Configuration ............................. 5
2.2 Less is More ....................................... 5
2.3 Diversity is Not a Benefit ......................... 6
2.4 Lower Layer Independence ........................... 7
2.5 Configuration is Not Access Control ................ 8
3. Additional Discussion .................................... 9
3.1 General Purpose Mechanisms ......................... 9
3.2 Service Discovery Protocols ........................ 9
3.3 Fate Sharing ....................................... 10
4. Security Considerations .................................. 11
4.1 Configuration Authentication ....................... 12
5. IANA Considerations ...................................... 13
6. References ............................................... 13
6.1 Informative References ............................. 13
Acknowledgments .............................................. 15
Authors' Addresses ........................................... 15
Full Copyright Statement ..................................... 16
Intellectual Property ........................................ 16
Aboba & Thaler Informational [Page 2]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
1. Introduction
"Architectural Principles of the Internet" [RFC1958] documents
architectural principles of the Internet. This document describes
principles of Internet host configuration. It covers issues relating
to configuration of parameters that affect the Internet layer, as
well as parameters affecting higher layer protocols.
In recent years, a number of architectural questions have arisen, for
which we provide guidance to protocol developers:
o What protocol layers and general approaches are most appropriate
for configuration of various parameters.
o The relationship between parameter configuration and service
discovery.
o The relationship between network access authentication and host
configuration.
o The role of link-layer protocols (including tunneling protocols)
in Internet host configuration.
The last point above is particularly important to address, since it
can directly affect the properties of a link as seen by higher layers
(for example, whether privacy extensions [RFC3041] are available to
applications).
1.1. Terminology
Internet layer configuration is defined as the configuration required
to support the operation of the Internet layer. This includes, for
example:
IP address(es)
IP address configuration includes both configuration of link-scope
addresses as well as global addresses. Configuration of IP
addresses is an important step, since this enables a host to fill
in the source address in the packets it sends, as well as to
receive packets destined to that address. As a result, the host
can now receive unicast IP packets, rather requiring that IP
packets be sent to the broadcast or multicast address.
Configuration of an IP address also enables the use of IP
fragmentation, since packets sent from the unknown address cannot
be reliably reassembled (fragments from multiple hosts using the
unknown address might be reassembled into a single IP packet).
Configuration of an IP address also enables use of security
facilities such as IPsec [RFC4301].
Aboba & Thaler Informational [Page 3]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
Subnet prefix(es)
Once a subnet prefix is configured, hosts with an IP address can
now send and receive unicast IP packets from on-link hosts.
Default gateway(s)
Once a default gateway is configured, hosts with an IP address can
now send and receive unicast IP packets from off-link hosts.
Mobility agent(s)
While Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] include their
own mechanisms for locating home agents, it is also possible for
mobile nodes to require dynamic home agent configuration.
Other parameters
Internet layer parameter configuration also includes configuration
of per-host (e.g. IP TTL, enabling/disabling of IP forwarding and
source routing) and per-interface parameters (e.g. MTU).
Boot service configuration
Boot service configuration is defined as the configuration
necessary for a host to obtain and perhaps also to verify an
appropriate boot image. This is appropriate for diskless hosts
looking to obtain a boot image via mechanisms such as TFTP
[RFC1350], NFS [RFC3530] and iSCSI [RFC3720,RFC4173]. It also may
be useful in situations where it is necessary to update the boot
image of a host that supports a disk, such as in the Preboot
eXecution Environment (PXE) [PXE][PXEOPT]. While strictly speaking
boot services operate above the Internet layer, where boot service
is used to obtain the Internet layer code, it may be considered
part of Internet layer configuration.
Higher-layer configuration is defined as the configuration required to
support the operation of other components above the Internet layer.
This includes, for example:
Name Service Configuration
Name service configuration includes the configuration required for
the host to resolve names. This includes configuration of the
addresses of name resolution servers, including IEN 116, DNS, WINS,
iSNS and NIS servers, and the setting of name resolution parameters
such as the NetBIOS node type, the DNS domain and search list, etc.
It may also include the transmission or setting of the host's own
name.
Once the host has completed name server configuration, it is able
to resolve names. This not only allows the host to communicate
with other hosts whose IP address is not known, but to the extent
that name services are utilized for service discovery, this also
Aboba & Thaler Informational [Page 4]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
enables the host to discover services available on the network or
elsewhere.
Time Service Configuration
Time service configuration includes configuration of servers for
protocols such as SNTP and NTP. Since accurate determination of
the time may be important to operation of the applications running
on the host (including security services), configuration of time
servers may be a prerequisite for higher layer operation. However,
it is typically not a requirement for Internet layer configuration.
Other service configuration
This can include discovery of additional servers and devices, such
as printers, SIP proxies, etc.
2. Principles
This Section describes basic principles of Internet host
configuration.
2.1. Minimize Configuration
Anything that can be configured can be misconfigured. [RFC1958]
Section 3.8 states: "Avoid options and parameters whenever possible.
Any options and parameters should be configured or negotiated
dynamically rather than manually."
That is, to minimize the possibility of configuration errors,
parameters should be automatically computed (or at least have
reasonable defaults) whenever possible. For example, TCP [RFC793]
does not require configuration of the Maximum Segment Size, but is
able to compute an appropriate value.
Sometimes the means by which a parameter is automatically computed by
a protocol involves message exchanges by which a protocol configures
itself. This is typical for capability negotiation, and often for
discovery of other devices that implement the same protocol.
2.2. Less is More
The availability of standardized, simple mechanisms for general-
purpose Internet host configuration is highly desirable. [RFC1958]
states, "Performance and cost must be considered as well as
functionality" and "Keep it simple. When in doubt during design,
choose the simplest solution."
To allow protocol support in more types of devices, it is important
to minimize the footprint requirement. For example, Internet hosts
Aboba & Thaler Informational [Page 5]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
span a wide range of devices, from embedded devices operating with
minimal footprint to supercomputers. Since the resources (memory,
code size) available for host configuration may be very small, it is
desirable for a host to able to configure itself in as simple a
manner as possible.
One interesting example is IP support in pre-boot execution
environments. Since by definition boot configuration is required in
hosts that have not yet fully booted, it is often necessary for pre-
boot code to be executed from ROM, with minimal available memory. In
PXE, prior to obtaining a boot image, the host is typically only be
able to communicate using IP and UDP. This is one reason why
Internet layer configuration mechanisms typically depend only on IP
and UDP. After obtaining the boot image, the host will have the full
facilities of TCP/IP available to it, including support for reliable
transport protocols, IPsec, etc.
In order to reduce complexity, it is desirable for Internet layer
configuration mechanisms to avoid dependencies on higher layers.
Since embedded hosts may wish to minimize the code included within a
boot ROM, availability of higher layer facilities cannot be
guaranteed during Internet layer configuration. In fact, it cannot
even be guaranteed that all Internet layer facilities will be
available. For example, IP fragmentation and reassembly may not work
reliably until a host has obtained an IP address.
2.3. Diversity is Not a Benefit
The number of host configuration mechanisms should be minimized.
Diversity in Internet host configuration mechanisms presents several
problems:
Interoperability
As configuration diversity increases, it becomes likely that a host
will not support the configuration mechanism(s) available on the
network to which it has attached, creating interoperability
problems.
Footprint
In order to be able to interoperate, hosts need to implement all
configuration mechanisms used on the media they support. This
increases the required footprint, a burden for embedded devices.
Redundancy
To support diversity in host configuration mechanism(s), 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 discernible
Aboba & Thaler Informational [Page 6]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
benefit.
Latency
As configuration diversity increases, hosts supporting multiple
configuration mechanisms may spend increasing effort to determine
which mechanism(s) are supported. This adds to configuration
latency.
Conflicts
Whenever multiple mechanisms are available, it is possible that
multiple configuration(s) will be returned. To handle this, hosts
would need to merge potentially conflicting configurations. This
would require conflict resolution logic, such as ranking of
potential configuration sources, increasing implementation
complexity.
Additional traffic
To limit configuration latency, hosts may simultaneously attempt to
obtain configuration by multiple mechanisms, increasing on-the-wire
traffic.
2.4. Lower Layer Independence
[RFC1958] states, "Modularity is good. If you can keep things
separate, do so."
It is becoming increasingly common for hosts to support multiple
network access mechanisms, including dialup, wireless and wired local
area networks, GPRS, CDMA 1X-RTT, etc. As a result, it is desirable
for hosts to be able to configure themselves on multiple networks
without adding configuration code specific to a new link layer.
As a result, it is highly desirable for Internet host configuration
mechanisms to be independent of the underlying lower layer. That is,
the link layer protocol (whether it be a physical link, or a virtual
tunnel link) should only be explicitly aware of link-layer parameters
(although it may configure link-layer parameters - see Section 2.1).
Introduction of lower layer dependencies increases the likelihood of
interoperability problems and adds to the number of Internet layer
configuration mechanisms that hosts need to implement.
Lower layer dependencies can be best avoided by keeping Internet host
configuration above the link layer, thereby enabling configuration to
be handled for any link layer that supports IP. In order to provide
media independence, Internet host configuration mechanisms should be
link-layer protocol independent.
While there are examples of IP address assignment within the link
Aboba & Thaler Informational [Page 7]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
layer (such PPP IPv4CP [RFC1332]), the disadvantages of this approach
have now become apparent. The main disadvantages include the extra
complexity of implementing different mechanisms on different link
layers, and the difficulty in adding new parameters which would
require defining a mechanism in each link layer protocol.
For example, PPP IPv4CP and IPCP extensions for name service
configuration [RFC1877] were developed at a time when DHCP [RFC2131]
had not yet been widely implemented on access devices or in service
provider networks. However, in IPv6 where link layer independent
mechanisms such as stateless address configuration [RFC2462] and
DHCPv6 [RFC2131,RFC3736] are available, PPP IPv6CP [RFC2472] instead
simply configures an Interface-Identifier which is similar to a MAC
address. In contrast, IKEv2 [RFC4306] repeats the same mistake as
PPP IPv4CP by defining a Configuration Payload for Internet host
configuration for both IPv4 and IPv6.
As a result, extensions to link layer protocols for the purpose of
Internet, Transport or Application layer configuration (including
server configuration) should be avoided. Such extensions can
negatively affect the properties of a link as seen by higher layers.
For example, if a link layer protocol (or tunneling protocol)
configures individual IPv6 addresses and precludes using any other
addresses, then this can break privacy extensions [RFC3041]. Hence
applications that desire privacy extensions may not function well.
Similar issues may arise for other types of addresses, such as
Cryptographically Generated Addresses [RFC3972], as well.
Avoidance of lower layer dependencies also applies even where the
lower layer in question may be link independent. For example, while
Extensible Authentication Protocol (EAP) [RFC3748] may be run over
any link satisfying the requirements of [RFC3748] Section 3.1, many
link layers do not support EAP and therefore Internet layer
configuration mechanisms with EAP dependencies would not usable on
all links that support IP.
2.5. Configuration is Not Access Control
Network access authentication is a distinct problem from Internet
host configuration. Network access authentication is best handled
independently of the configuration mechanisms in use for the Internet
and higher layers.
For example, attempting to control access by requiring authentication
in order to obtain configuration parameters (such as an IP address)
has little value if the user can manually configure the host. Having
an Internet (or higher) layer protocol authenticate clients is
appropriate to prevent resource exhaustion of a scarce resource on
Aboba & Thaler Informational [Page 8]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
the server, but not for preventing rogue hosts from obtaining access
to a link. Note that client authentication is not required for
Stateless DHCPv6 [RFC3736] since it does not result in allocation of
any limited resources on the server.
3. Additional Discussion
3.1. General Purpose Mechanisms
Protocols should either be self-configuring (especially where fate
sharing is important), or use general-purpose configuration
mechanisms. Given the number of Internet host configuration
mechanisms that have already been defined, and the problems resulting
from the proliferation of these mechanisms, there is no apparent need
for the development of additional general-purpose configuration
mechanisms.
When defining a new host parameter, protocol designers should first
consider whether configuration is indeed necessary (see Section 2.1
for further discussion). If configuration is necessary, protocol
designers should next consider:
1. Where the authoritative source of information is. For example,
routers are authoritative for default gateway information, DNS
servers are authoritative for DNS server information, etc.
2. Which type of administrator would be the source of the
information. For example, router administrators and server
administrators are often different sets of individuals.
3. Whether the parameter is a per-interface parameter or a global
parameter. For example, most standard general purpose
configuration protocols run on a per-interface basis and hence
are more appropriate for per-interface parameters.
Finally, protocol designers should choose to either make the protocol
that needs the parameter be self-configuring, or use the most
appropriate general purpose configuration mechanism (generally DHCP,
but possibly a service discovery protocol as noted below in Section
3.2). The choice should be made taking into account all of the
principles discussed in Section 2.
3.2. Service Discovery Protocols
Higher-layer configuration often includes configuring addresses of
servers. Hence the question arises as to how this differs from
"service discovery" as provided by Service Discovery protocols such
as SLPv2 [RFC2608].
Aboba & Thaler Informational [Page 9]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
In general-purpose configuration mechanisms such as DHCP, hosts on
the same link are typically considered equivalent, and server
instances are likewise considered equivalent. In service discovery
protocols, on the other hand, a host desires to find a server
satisfying a particular set of criteria, where the set of criteria
may vary by request.
In addition, service discovery protocols such as SLPv2 can support
discovery of servers on the Internet [RFC3832], not just those within
the local network. General-purpose configuration mechanisms such as
DHCP, on the other hand, typically assume the server(s) in the local
network contain the authoritative set of information.
For the service discovery problem (i.e., where the criteria varies on
a per-request basis, even from the same host), protocols should
either be self-discovering (if fate sharing is critical), or use
general purpose service discovery mechanisms.
In order to avoid a dependency on multicast routing, it is necessary
for a host to either restrict discovery to services on the local link
or to discover the location of the Directory Agent (DA). Therefore
the use of service discovery protocols beyond the local link is
typically dependent on a parameter configuration mechanism. As a
result, service discovery protocols are typically not appropriate for
use in obtaining basic Internet layer configuration, although they
can be used to obtain higher-layer configuration for parameters that
don't meet the assumptions above made by general-purpose
configuration mechanisms.
3.3. Fate Sharing
If a server (or set of servers) is needed to get a set of
configuration parameters, "fate sharing" ([RFC1958] Section 2.3) is
preserved if the servers are ones without which the parameters could
not be used, even if they were obtained via other means. For
example, learning the default gateways from the gateways themselves
via Router Advertisements provides perfect fate sharing. That is,
the parameters can be obtained if and only if they can actually be
used. Furthermore, the possibility of incorrect information being
configured is minimized if there is only one machine which is
authoritative for the information (i.e., there is no need to keep
multiple authoritative servers in sync).
While fate sharing is a desirable property of a configuration
mechanism, existing configuration schemes typically only provide for
fate sharing in limited circumstances. When utilized to discover
services on the local link, service discovery protocols typically
provide for fate sharing, since hosts providing service information
Aboba & Thaler Informational [Page 10]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
typically also provide the services. However, where service
discovery is assisted by a DA, fate sharing is typically not
supported. The ability to discover services is dependent on whether
the DA is operational, even though the DA is typically not involved
in the delivery of the service. Since the DA and service agents
(SAs) can be out of synchronization, it is possible for the DA to
provide service information that is no longer current. For example,
service descriptions provided to the DA by SAs might be included in
response to service discovery queries even after the SAs were no
longer operational. Similarly, recently introduced services might
not yet have been registered by the DA.
Similar limitations exist for other server-based configuration
mechanisms such as DHCP. For example, typically DHCP servers do not
check for the liveness of the configuration information they provide,
or discover new configuration information automatically. As a
result, there is no guarantee that configuration information will be
current. "IPv6 Host configuration of DNS Server Information
Approaches" [RFC4339] Section 3.3 discusses the use of well-known
anycast addresses for discovery of DNS servers. The use of anycast
addresses enables fate sharing, even where the anycast address is
provided by an unrelated server. However, in order to be universally
useful, this approach would require allocation of a well-known
anycast address for each service.
4. Security Considerations
Today IP configuration is typically not secured. For example, PPP
IPv4CP [RFC1332] does not support secure negotiation, enabling an
attacker with access to the link to subvert the negotiation. DHCPv4
[RFC2131] initially did not include support for security; this was
added in [RFC3118]. DHCPv6 [RFC3736] does include security support.
However, DHCP authentication is not yet widely implemented for either
DHCPv4 or DHCPv6.
A number of issues exist with various classes of parameters, as
discussed in Section 2.6, [RFC3756] Section 4.2.7, [RFC3118] Section
1.1, and [RFC3315] Section 23. Given the potential vulnerabilities
resulting from implementation of these options, it is currently
common for hosts to restrict support for DHCP options to the minimum
set required to provide basic TCP/IP configuration.
Securing Internet layer configuration requires securing the protocol
used to obtain it: Secure Neighbor Discovery (SEND) [RFC3971] for
stateless address autoconfiguration, or DHCP authentication for
stateful address configuration.
Aboba & Thaler Informational [Page 11]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
4.1. Configuration Authentication
While most threats against configuration mechanisms result in denial-
of-service, some parameters are more critical. For example, since
boot configuration determines the boot image to be run by the host, a
successful attack on boot configuration could result in an attacker
gaining complete control over a host. As a result, it is
particularly important that boot configuration be secured.
Internet host configuration parameters fall into two categories:
those that are necessary for basic IP unicast connectivity (Internet
layer configuration), and those that aren't (Higher layer
configuration).
The techniques available for securing Internet layer configuration
are inherently limited, since classic security protocols such as
IPsec [RFC4301] or TLS [RFC4346] cannot be used since an IP address
is not yet available. Use of lower layer security mechanisms are
limited by the "lower layer independence" principle.
As a result, security mechanisms have typically been implemented
within the configuration protocols themselves. For example, IPv6
supports SEcure Neighbor Discovery (SEND) [RFC3971], DHCPv4 supports
DHCP authentication [RFC3118], and DHCPv6 supports an equivalent
facility [RFC3315].
Higher layer configuration parameters, however, typically do not have
this problem. When stateful DHCPv6 uses authentication for Internet
layer configuration, higher-layer configuration parameters can be
similarly secured. However, even if a host does not support DHCPv6
authentication, higher-layer configuration via Stateless DHCPv6
[RFC2462] can still be secured with IPsec. Possible exceptions to
this may exist where security facilities may not yet be available
until later in the boot process. For example, it may be difficult to
secure boot configuration even once the Internet layer has been
configured, because security code may not become available until
after boot configuration has been completed. For example, Kerberos,
IPsec or TLS may not yet be available.
Finally, where public key cryptography is used to authenticate and
integrity protect configuration, hosts need to be configured with
trust anchors in order to validate received configuration messages.
For a node which visits multiple administrative domains, acquiring
the required trust anchors may be difficult. This is left as an area
for future work.
Aboba & Thaler Informational [Page 12]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
5. IANA Considerations
This document has no actions for IANA.
6. References
6.1. Informative References
[PXE] Henry, M. and M. Johnston, "Preboot Execution Environment
(PXE) Specification", September 1999,
http://www.pix.net/software/pxeboot/archive/pxespec.pdf
[PXEOPT] Johnston, M., "DHCP Options for the Intel Preboot eXecution
Environment (PXE)", draft-ietf-dhc-pxe-options-03.txt,
Internet draft (work in progress), March 2006.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[RFC1332] McGregor, G., "PPP Internet Control Protocol", RFC 1332,
Merit, May 1992.
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC
1350, July 1992.
[RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol Extensions
for Name Server Addresses", RFC 1877, December 1995.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC
1958, June 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998.
[RFC2608] Guttman, E., et al., "Service Location Protocol, Version 2",
RFC 2608, June 1999.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
Aboba & Thaler Informational [Page 13]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
[RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C.
and M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M. and D. Noveck, "Network File System (NFS)
version 4 Protocol", RFC 3530, April 2003.
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and E.
Zeidner, "Internet Small Computer Systems Interface (iSCSI)",
RFC 3720, April 2004.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C. and W.
Jerome, "Remote Service Discovery in the Service Location
Protocol (SLP) via DNS SRV", RFC 3832, July 2004.
[RFC3971] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March
2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC
3972, March 2005.
[RFC4173] Sarkar, P., Missimer, D. and C. Sapuntzakis, "Bootstrapping
Clients using the iSCSI Protocol", RFC 4173, September 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
Aboba & Thaler Informational [Page 14]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
[RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information
Approaches", RFC 4339, February 2006.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
Acknowledgments
Bob Hinden and James Kempf provided valuable input on this document.
Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: dthaler@microsoft.com
Aboba & Thaler Informational [Page 15]
INTERNET-DRAFT Principles of Host Configuration 24 February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Aboba & Thaler Informational [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-22 13:53:10 |