< draft-ietf-autoconf-adhoc-addr-model-02.txt   draft-ietf-autoconf-adhoc-addr-model-03.txt >
Autoconf E. Baccelli, Ed. Autoconf E. Baccelli, Ed.
Internet-Draft INRIA Internet-Draft INRIA
Intended status: Informational M. Townsley, Ed. Intended status: Informational M. Townsley, Ed.
Expires: July 25, 2010 Cisco Systems Expires: September 23, 2010 Cisco Systems
January 25, 2010 March 22, 2010
IP Addressing Model in Ad Hoc Networks IP Addressing Model in Ad Hoc Networks
draft-ietf-autoconf-adhoc-addr-model-02 draft-ietf-autoconf-adhoc-addr-model-03
Abstract Abstract
This document describes a model for configuring IP addresses and This document describes a model for configuring IP addresses and
subnet prefixes on the interfaces of routers which connect to links subnet prefixes on the interfaces of routers which connect to links
with undetermined connectivity properties. with undetermined connectivity properties.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 July 25, 2010. This Internet-Draft will expire on September 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 4
4. IP Subnet Prefix Configuration . . . . . . . . . . . . . . . . 4 4. IP Subnet Prefix Configuration . . . . . . . . . . . . . . . . 4
5. IP Address Configuration . . . . . . . . . . . . . . . . . . . 5 5. IP Address Configuration . . . . . . . . . . . . . . . . . . . 4
6. Addressing Model . . . . . . . . . . . . . . . . . . . . . . . 5 6. Addressing Model . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. IPv6 Model . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. IPv6 Model . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2. IPv4 Model . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. IPv4 Model . . . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Changes since -01 . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The appropriate configuration of IP addresses and subnet masks for The appropriate configuration of IP addresses and subnet masks for
router network interfaces is generally a prerequisite to the correct router network interfaces is generally a prerequisite to the correct
functioning of routing protocols. Consideration of various items, functioning of routing protocols. Consideration of various items,
including underlying link capabilities and connectivity, geographical including underlying link capabilities and connectivity, geographical
topology, available address blocks, assumed traffic patterns, topology, available address blocks, assumed traffic patterns
etc. are used when determining the appropriate network topology and etc., are used when determining the appropriate network topology and
the associated IP interface configuration. the associated IP interface configuration.
When the capabilities and connectivity of the links that connect When the capabilities and connectivity of the links that connect
routers are well-known and stable, logical network topology design routers are well-known and stable, logical network topology design
and corresponding IP interface configuration are straightforward. and corresponding IP interface configuration are straightforward.
Absent any assumption about link-level connectivity, however, there Absent any assumption about link-level connectivity, however, there
is no canonical method for determining a given IP interface is no canonical method for determining a given IP interface
configuration. configuration.
Link-level connectivity is generally qualified as undetermined when Link-level connectivity is generally qualified as undetermined when
skipping to change at page 3, line 38 skipping to change at page 3, line 38
interfaces are configured with IP addresses. This document thus interfaces are configured with IP addresses. This document thus
proposes a model for configuration of IP addresses and subnet proposes a model for configuration of IP addresses and subnet
prefixes on router interfaces to links with undetermined connectivity prefixes on router interfaces to links with undetermined connectivity
properties, to allow routing protocols and data packet forwarding to properties, to allow routing protocols and data packet forwarding to
function. function.
Note that routers may ultimately need additional IP prefixes for the Note that routers may ultimately need additional IP prefixes for the
diverse applications that could run directly on the routers diverse applications that could run directly on the routers
themselves, or for assignment to attached hosts or networks. For themselves, or for assignment to attached hosts or networks. For
IPv6, these addresses may be global [RFC3587], Unique-Local [RFC4193] IPv6, these addresses may be global [RFC3587], Unique-Local [RFC4193]
or Link-Local [RFC4291]. For IPv4, the addresses may be global (i.e. or Link-Local [RFC4291]. For IPv4, the addresses may be global
public) or private [RFC1918]. In general, global scope is desired (i.e., public) or private [RFC1918]. In general, global scope is
over local scope, though it is understood that this may not always be desired over local scope, though it is understood that this may not
achievable via automatic configuration mechanisms. In this document always be achievable via automatic configuration mechanisms. In this
however, automatic configuration of the prefixes used for general document however, automatic configuration of the prefixes used for
applications is considered as a problem that is separable from that general applications is considered as a problem that is separable
of automatic configuration of addresses and prefixes necessary for from that of automatic configuration of addresses and prefixes
routing protocols to function. This document thus focuses on the necessary for routing protocols to function. This document thus
latter: the type of IP address and subnet mask configuration focuses on the latter: the type of IP address and subnet mask
necessary for routing protocols and data packet forwarding to configuration necessary for routing protocols and data packet
function. forwarding to function.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document uses the vocabulary and the concepts defined in
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and [RFC1918] and [RFC4632] for IPv4, as well as [RFC4291] for IPv6.
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. Moreover, this document uses the vocabulary and the
concepts defined in [RFC1918] and [RFC4632] for IPv4, as well as
[RFC4291] for IPv6.
3. Applicability Statement 3. Applicability Statement
The configuration proposed by this model is applicable to any This model gives guidance about the configuration of IP addresses and
router's IP interface. It specifies IP addresses and IP subnet the IP subnet prefixes on router's IP interfaces which connect to
prefixes to be configured on network interfaces. links with undetermined connectivity properties.
When more specific assumptions can be made regarding the connectivity When more specific assumptions can be made regarding the connectivity
between interfaces, or the (persistent) reachability of some between interfaces, or the (persistent) reachability of some
addresses, these SHOULD be considered when configuring subnet addresses, these should be considered when configuring subnet
prefixes. prefixes.
4. IP Subnet Prefix Configuration 4. IP Subnet Prefix Configuration
If the link to which an interface connects enables no assumptions of If the link to which an interface connects enables no assumptions of
connectivity to other interfaces, the only addresses which can be connectivity to other interfaces, the only addresses which can be
assumed "on link", are the address(es) of that interface itself. assumed "on link", are the address(es) of that interface itself.
Note that while link-local addresses are assumed to be "on link", the Note that while link-local addresses are assumed to be "on link", the
utility of link-local addresses is limited as described in Section 6. utility of link-local addresses is limited as described in Section 6.
Subnet prefix configuration on such interfaces must thus not make any Subnet prefix configuration on such interfaces must thus not make any
promises in terms of direct (one hop) IP connectivity to IP addresses promises in terms of direct (one hop) IP connectivity to IP addresses
other than that of the interface itself. This suggests the following other than that of the interface itself. This suggests the following
principle: principle:
o no on-link subnet prefix should be configured on such an o no on-link subnet prefix should be configured on such an
interface. interface.
If L2 communication is enabled between a pair of interfaces, IP Note that if layer 2 communication is enabled between a pair of
packet exchange is enabled regardless of the IP subnet configuration interfaces, IP packet exchange is also enabled, even if IP subnet
on each of these interfaces. configuration is absent or different on each of these interfaces.
If on the contrary, assumptions can be made regarding the Also note that if, on the contrary, assumptions can be made regarding
connectivity between interfaces, or regarding the persistent the connectivity between interfaces, or regarding the persistent
reachability of some addresses, these SHOULD be considered when reachability of some addresses, these should be considered when
configuring IP subnet prefixes, and the corresponding interface(s) configuring IP subnet prefixes, and the corresponding interface(s)
MAY in such case be configured with an on-link subnet prefix. may in such case be configured with an on-link subnet prefix.
5. IP Address Configuration 5. IP Address Configuration
Routing protocols running on a router may exhibit different Routing protocols running on a router may exhibit different
requirements for uniqueness of interface addresses; some have no such requirements for uniqueness of interface addresses; some have no such
requirements, others have requirements ranging from local uniqueness requirements, others have requirements ranging from local uniqueness
only, to uniqueness within, at least, the routing domain (as defined only, to uniqueness within, at least, the routing domain (as defined
in [RFC1136]). in [RFC1136]).
Configuring an IP address that is unique within the routing domain Configuring an IP address that is unique within the routing domain
skipping to change at page 5, line 31 skipping to change at page 5, line 27
least within the routing domain. least within the routing domain.
6. Addressing Model 6. Addressing Model
Section 4 and Section 5 describe principles for IP address and subnet Section 4 and Section 5 describe principles for IP address and subnet
prefix configuration on an interface of a router, when that interface prefix configuration on an interface of a router, when that interface
connects to a link with undetermined connectivity properties. The connects to a link with undetermined connectivity properties. The
following describes guidelines that follow from these principles, following describes guidelines that follow from these principles,
respectively for IPv6 and IPv4. respectively for IPv6 and IPv4.
Note that the guidelines provided in this document slightly differ
for IPv6 and IPv4, as IPv6 offers possibilities that IPv4 does not
(i.e., the possibility to simply not configure any on-link subnet
prefix on an IPv6 interface), which provide a "cleaner" model.
6.1. IPv6 Model 6.1. IPv6 Model
For IPv6, the principles described in Section 4 and Section 5 suggest For IPv6, the principles described in Section 4 and Section 5 suggest
the following rules: the following rules:
o An IP address configured on this interface should be unique, at o An IP address configured on this interface should be unique, at
least within the routing domain, and least within the routing domain, and
o No on-link subnet prefix is configured on this interface. o No on-link subnet prefix is configured on this interface.
Note that while an IPv6 link-local address is assigned to each Note that while an IPv6 link-local address is assigned to each
interface as per [RFC4291], in general link-local addresses are of interface as per [RFC4291], in general link-local addresses are of
limited utility on links with undetermined connectivity, as limited utility on links with undetermined connectivity, as
connectivity to neighbors may be constantly changing. The known connectivity to neighbors may be constantly changing. The known
limitations are: limitations are:
o There is no mechanism to ensure that IPv6 link-local addresses are o There is no mechanism to ensure that IPv6 link-local addresses are
unique across multiple links, hence they can not be used to unique across multiple links, hence they cannot be used to
reliably identify routers. reliably identify routers (it is often desirable to identify a
router with an IP address).
o Routers cannot forward any packets with link-local source or o Routers cannot forward any packets with link-local source or
destination addresses to other links (as per [RFC4291]) while most destination addresses to other links (as per [RFC4291]) while most
of the time, routers need to be able to forward packets to/from of the time, routers need to be able to forward packets to/from
different links. different links.
Therefore, autoconfiguration solutions should be encouraged to Therefore, autoconfiguration solutions should be encouraged to
primarily focus on configuring IP addresses that are not IPv6 link- primarily focus on configuring IP addresses that are not IPv6 link-
local. local.
6.2. IPv4 Model 6.2. IPv4 Model
For IPv4, the principles described in Section 4 and Section 5 suggest For IPv4, the principles described in Section 4 and Section 5 suggest
rules similar to those mentioned for IPv6 in Section 6.1, that are: rules similar to those mentioned for IPv6 in Section 6.1, that are:
o An IP address configured on this interface should be unique, at o An IP address configured on this interface should be unique, at
least within the routing domain, and least within the routing domain, and
o Any subnet prefix configured on this interface should be of length o Any subnet prefix configured on this interface should be 32 bits
/32. long.
Note that the use of IPv4 link-local addresses [RFC3927] in this Note that the use of IPv4 link-local addresses [RFC3927] in this
context should be discouraged for most applications, as the context should be discouraged for most applications, as the
limitations outlined in Section 6.1 for IPv6 link-local addresses limitations outlined in Section 6.1 for IPv6 link-local addresses
also concern IPv4 link-local addresses. These limitations are also concern IPv4 link-local addresses. These limitations are
further exacerbated by the smaller pool of IPv4 link-local addresses further exacerbated by the smaller pool of IPv4 link-local addresses
to choose from and thus increased reliance on DAD. to choose from and thus increased reliance on Duplicate Address
Detection (DAD).
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Security Considerations 8. Security Considerations
This document thus focuses on the IP address and subnet mask This document thus focuses on the IP address and subnet mask
configuration necessary for routing protocols and data packet configuration necessary for routing protocols and data packet
forwarding to function. [RFC4593] describes generic threats to forwarding to function. [RFC4593] describes generic threats to
skipping to change at page 7, line 6 skipping to change at page 7, line 9
the addressing model described in this document does not introduce the addressing model described in this document does not introduce
new security threats. new security threats.
However, the possible lack of pre-established infrastructure or However, the possible lack of pre-established infrastructure or
authority, as enabled by the use of interfaces with undetermined authority, as enabled by the use of interfaces with undetermined
connectivity properties, may render some of the attacks described in connectivity properties, may render some of the attacks described in
[RFC4593] easier to undertake. In particular, detection of [RFC4593] easier to undertake. In particular, detection of
malevolent misconfiguration may be more difficult to detect and to malevolent misconfiguration may be more difficult to detect and to
locate. locate.
9. Normative References 9. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 9.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing
Domains: A Model for Routing in the Internet", RFC 1136, Domains: A Model for Routing in the Internet", RFC 1136,
December 1989. December 1989.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, 2006. Architecture", RFC 4291, 2006.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, Configuration of IPv4 Link-Local Addresses", RFC 3927,
skipping to change at page 7, line 36 skipping to change at page 7, line 38
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, 2005. Addresses", RFC 4193, 2005.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, 2003. Unicast Address Format", RFC 3587, 2003.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", RFC 4632, 2006. Plan", RFC 4632, 2006.
9.2. Informative References
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, 2006. Routing Protocols", RFC 4593, 2006.
Appendix A. Changes since -01 Appendix A. Contributors
This section logs the main changes of this document since its last
version. These are:
RFC 1136 - added reference to RFC 1136 to precise the term routing
domain.
Routing and Data Forwarding - in the introduction, added the
precision that the goal is to allow both routing protocols and
data packet forwarding to function.
Security section - added content in the security section.
Appendix B. Contributors
This document reflects discussions and contributions from several This document reflects discussions and contributions from several
individuals including (in alphabetical order): Teco Boot, Ulrich individuals including (in alphabetical order): Teco Boot, Ulrich
Herberg, Thomas Narten, Erik Nordmark, Charles Perkins, Zach Shelby Herberg, Thomas Narten, Erik Nordmark, Charles Perkins, Zach Shelby
and Dave Thaler. and Dave Thaler.
Authors' Addresses Authors' Addresses
Emmanuel Baccelli Emmanuel Baccelli
INRIA INRIA
 End of changes. 21 change blocks. 
61 lines changed or deleted 52 lines changed or added

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