draft-iab-ip-config-09.txt   draft-iab-ip-config-10.txt 
Network Working Group B. Aboba Network Working Group B. Aboba
INTERNET-DRAFT D. Thaler INTERNET-DRAFT D. Thaler
Category: Informational Loa Andersson Category: Informational Loa Andersson
Expires: June 5, 2009 Stuart Cheshire Expires: July 5, 2009 Stuart Cheshire
9 December 2008 Internet Architecture Board 19 December 2008 Internet Architecture Board
Principles of Internet Host Configuration Principles of Internet Host Configuration
draft-iab-ip-config-09.txt draft-iab-ip-config-10.txt
By submitting this Internet-Draft, each author represents that any Status of This Memo
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 This Internet-Draft is submitted to IETF in full conformance with the
aware will be disclosed, in accordance with Section 6 of BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 5, 2009. This Internet-Draft will expire on July 5, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 25 skipping to change at page 2, line 31
2.5 Configuration is Not Access Control ................ 11 2.5 Configuration is Not Access Control ................ 11
3. Additional Discussion .................................... 11 3. Additional Discussion .................................... 11
3.1 Reliance on General Purpose Mechanisms ............. 11 3.1 Reliance on General Purpose Mechanisms ............. 11
3.2 Relationship between IP Configuration and 3.2 Relationship between IP Configuration and
Service Discovery .................................. 12 Service Discovery .................................. 12
3.3 Discovering Names vs. Addresses .................... 14 3.3 Discovering Names vs. Addresses .................... 14
3.4 Dual Stack Issues .................................. 15 3.4 Dual Stack Issues .................................. 15
3.5 Relationship between Per-Interface and 3.5 Relationship between Per-Interface and
Per-Host Configuration ............................. 16 Per-Host Configuration ............................. 16
4. Security Considerations .................................. 17 4. Security Considerations .................................. 17
4.1 Configuration Authentication ....................... 18 4.1 Configuration Authentication ....................... 17
5. IANA Considerations ...................................... 19 5. IANA Considerations ...................................... 19
6. References ............................................... 19 6. References ............................................... 19
6.1 Informative References ............................. 19 6.1 Informative References ............................. 19
Acknowledgments .............................................. 23 Acknowledgments .............................................. 23
Appendix A - IAB Members ..................................... 23 Appendix A - IAB Members ..................................... 23
Authors' Addresses ........................................... 24 Authors' Addresses ........................................... 24
Full Copyright Statement ..................................... 25
Intellectual Property ........................................ 25
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:
skipping to change at page 16, line 51 skipping to change at page 16, line 51
basis. This requires that the host prioritize them (e.g. basis. This requires that the host prioritize them (e.g.
most trusted to least trusted). most trusted to least trusted).
Name service configuration Name service configuration
While name service configuration is provided on a per- While name service configuration is provided on a per-
interface basis, name resolution configuration typically interface basis, name resolution configuration typically
will affect behavior of the host as a whole. For example, will affect behavior of the host as a whole. For example,
given the configuration of DNS server addresses and given the configuration of DNS server addresses and
searchlist parameters on each interface, the host searchlist parameters on each interface, the host
determines what sequence of name service queries is to be determines what sequence of name service queries is to be
sent on which interfaces, as well as how the answers are sent on which interfaces.
prioritized (e.g. first answered returned, most trusted
answer preferred, etc.).
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
skipping to change at page 18, line 30 skipping to change at page 18, line 23
typically implemented within the configuration protocols themselves. typically implemented within the configuration protocols 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, in situations where configuration spoofing. For example, a Network Access Server (NAS)
configuration packets only originate on a wired link, an Access Point acting as a DHCP relay can only permit incoming DHCP packets sent to
can filter incoming configuration packets on wireless links, such as the client port originating from DHCP server addresses. To prevent
IPv6 Router Advertisement packets (ICMP Type 134), DHCPv4 packets
sent to the client port (68), and DHCPv6 packets sent to the client
port (546). On the wired link, a Network Access Server (NAS) acting
as a DHCP relay can only permit incoming DHCP packets sent to the
client port originating from DHCP server addresses. To prevent
spoofing, communication between the DHCP Relay and Server can be spoofing, communication between the DHCP Relay and Server can be
authenticated and integrity protected using a mechanism such as authenticated and integrity protected using a mechanism such as
IPsec. IPsec. Where configuration packets can only originate on a wired
link, incoming configuration packets on wireless links can be
discarded, such as IPv6 Router Advertisement packets (ICMP Type 134),
DHCPv4 packets sent to the client port (68), and DHCPv6 packets sent
to the client port (546).
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.
skipping to change at page 25, line 4 skipping to change at line 1094
Acreo AB Acreo AB
EMail: loa@pi.nu EMail: loa@pi.nu
Stuart Cheshire Stuart Cheshire
Apple Computer, Inc. Apple Computer, Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
EMail: chesire [at] apple [dot] com EMail: chesire [at] apple [dot] com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 11 change blocks. 
24 lines changed or deleted 27 lines changed or added

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