IP Addressing Model in Ad Hoc Networks
How to configure router interface addresses and subnet prefixes when you cannot know who is on the other end of the link.
Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, September 2010, <https://www.rfc-editor.org/info/rfc5889>.
@misc{rfc5889,
series = {Request for Comments},
number = 5889,
howpublished = {RFC 5889},
publisher = {RFC Editor},
doi = {10.17487/RFC5889},
url = {https://www.rfc-editor.org/info/rfc5889},
author = {E. Baccelli and M. Townsley},
title = {{IP Addressing Model in Ad Hoc Networks}},
pagetotal = 8,
year = 2010,
month = sep,
} RFC text
Contents
Internet Engineering Task Force (IETF) E. Baccelli, Ed.
Request for Comments: 5889 INRIA
Category: Informational M. Townsley, Ed.
ISSN: 2070-1721 Cisco Systems
September 2010
IP Addressing Model in Ad Hoc Networks
Abstract
This document describes a model for configuring IP addresses and
subnet prefixes on the interfaces of routers which connect to links
with undetermined connectivity properties.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5889.
Copyright Notice
Copyright (c) 2010 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 4
4. IP Subnet Prefix Configuration . . . . . . . . . . . . . . . . 4
5. IP Address Configuration . . . . . . . . . . . . . . . . . . . 4
6. Addressing Model . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. IPv6 Model . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2. IPv4 Model . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The appropriate configuration of IP addresses and subnet masks for
router network interfaces is generally a prerequisite to the correct
functioning of routing protocols. Consideration of various items,
including underlying link capabilities and connectivity, geographical
topology, available address blocks, assumed traffic patterns etc.,
are used when determining the appropriate network topology and the
associated IP interface configuration.
When the capabilities and connectivity of the links that connect
routers are well-known and stable, logical network topology design
and corresponding IP interface configuration are straightforward.
Absent any assumption about link-level connectivity, however, there
is no canonical method for determining a given IP interface
configuration.
Link-level connectivity is generally qualified as undetermined when
it is unplanned and/or time-varying in character. Ad hoc networks
are typical examples of networks with undetermined link-level
connectivity. Routing protocols for ad hoc networks are purposely
designed to detect and maintain paths across the network, even when
faced with links with undetermined connectivity, assuming that
routers' interfaces are configured with IP addresses. This document
thus proposes a model for configuration of IP addresses and subnet
prefixes on router interfaces to links with undetermined connectivity
properties, to allow routing protocols and data packet forwarding to
function.
Note that routers may ultimately need additional IP prefixes for the
diverse applications that could run directly on the routers
themselves, or for assignment to attached hosts or networks. For
IPv6, these addresses may be global [RFC3587], Unique-Local [RFC4193]
or Link-Local [RFC4291]. For IPv4, the addresses may be global
(i.e., public) or private [RFC1918]. In general, global scope is
desired over local scope, though it is understood that this may not
always be achievable via automatic configuration mechanisms. In this
document however, automatic configuration of the prefixes used for
general applications is considered as a problem that is separable
from that of automatic configuration of addresses and prefixes
necessary for routing protocols to function. This document thus
focuses on the latter: the type of IP address and subnet mask
configuration necessary for routing protocols and data packet
forwarding to function.
2. Terminology
This document uses the vocabulary and the concepts defined in
[RFC1918] and [RFC4632] for IPv4, as well as [RFC4291] for IPv6.
3. Applicability Statement
This model gives guidance about the configuration of IP addresses and
the IP subnet prefixes on a router's IP interfaces, which connect to
links with undetermined connectivity properties.
When more specific assumptions can be made regarding the connectivity
between interfaces or the (persistent) reachability of some
addresses, these should be considered when configuring subnet
prefixes.
4. IP Subnet Prefix Configuration
If the link to which an interface connects enables no assumptions of
connectivity to other interfaces, the only addresses that can be
assumed "on link", are the address(es) of that interface itself.
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.
Thus, subnet prefix configuration on such interfaces must not make
any promises in terms of direct (one hop) IP connectivity to IP
addresses other than that of the interface itself. This suggests the
following principle:
o no on-link subnet prefix should be configured on such an
interface.
Note that if layer 2 communication is enabled between a pair of
interfaces, IP packet exchange is also enabled, even if IP subnet
configuration is absent or different on each of these interfaces.
Also note that if, on the contrary, assumptions can be made regarding
the connectivity between interfaces, or regarding the persistent
reachability of some addresses, these should be considered when
configuring IP subnet prefixes, and the corresponding interface(s)
may in such case be configured with an on-link subnet prefix.
5. IP Address Configuration
Routing protocols running on a router may exhibit different
requirements for uniqueness of interface addresses; some have no such
requirements, others have requirements ranging from local uniqueness
only, to uniqueness within, at least, the routing domain (as defined
in [RFC1136]).
Routing protocols that do not require unique IP addresses within the
routing domain utilize a separate unique identifier within the
routing protocol itself; such identifiers could be based on factory
assignment or configuration.
Nevertheless, configuring an IP address that is unique within the
routing domain satisfies the less stringent uniqueness requirements,
while also enabling protocols that have the most stringent
requirements of uniqueness within the routing domain. As a result,
the following principle allows for IP autoconfiguration to apply to
the widest array of routing protocols:
o an IP address assigned to an interface that connects to a link
with undetermined connectivity properties should be unique, at
least within the routing domain.
6. Addressing Model
Sections 4 and 5 describe principles for IP address and subnet prefix
configuration on an interface of a router, when that interface
connects to a link with undetermined connectivity properties. The
following describes guidelines that follow from these principles,
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
For IPv6, the principles described in Sections 4 and 5 suggest the
following rules:
o An IP address configured on this interface should be unique, at
least within the routing domain, and
o No on-link subnet prefix is configured on this interface.
Note that while an IPv6 link-local address is assigned to each
interface as per [RFC4291], in general link-local addresses are of
limited utility on links with undetermined connectivity, as
connectivity to neighbors may be constantly changing. The known
limitations are:
o In general, there is no mechanism to ensure that IPv6 link-local
addresses are unique across multiple links, though link-local
addresses using an IID that are of the modified EUI-64 form should
be globally unique.
o Routers cannot forward any packets with link-local source or
destination addresses to other links (as per [RFC4291]), while
most of the time, routers need to be able to forward packets to/
from different links.
Therefore, autoconfiguration solutions should be encouraged to
primarily focus on configuring IP addresses that are not IPv6 link-
local.
6.2. IPv4 Model
For IPv4, the principles described in Sections 4 and 5 suggest 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
least within the routing domain, and
o Any subnet prefix configured on this interface should be 32 bits
long.
Note that the use of IPv4 link-local addresses [RFC3927] in this
context should be discouraged for most applications, as the
limitations outlined in Section 6.1 for IPv6 link-local addresses
also concern IPv4 link-local addresses. These limitations are
further exacerbated by the smaller pool of IPv4 link-local addresses
to choose from and thus increased reliance on Duplicate Address
Detection (DAD).
7. Security Considerations
This document focuses on the IP address and subnet mask configuration
necessary for routing protocols and data packet forwarding to
function. [RFC4593] describes generic threats to routing protocols,
whose applicability is not altered by the presence of interfaces with
undetermined connectivity properties. As such, the addressing model
described in this document does not introduce new security threats.
However, the possible lack of pre-established infrastructure or
authority, as enabled by the use of interfaces with undetermined
connectivity properties, may render some of the attacks described in
[RFC4593] easier to undertake. In particular, detection of
malevolent misconfiguration may be more difficult to detect and to
locate.
8. References
8.1. Normative References
[RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing
Domains: A model for routing in the Internet", RFC 1136,
December 1989.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
8.2. Informative References
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, October 2006.
Appendix A. Contributors
This document reflects discussions and contributions from several
individuals including (in alphabetical order): Teco Boot, Thomas
Clausen, Ulrich Herberg, Thomas Narten, Erik Nordmark, Charles
Perkins, Zach Shelby, and Dave Thaler.
Authors' Addresses
Emmanuel Baccelli (editor)
INRIA
EMail: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/
Mark Townsley (editor)
Cisco Systems
EMail: mark@townsley.net
ISO Plain Language
On this page
§1The Problem with Links of Undetermined Connectivity
Choosing the right IP addresses and subnet masks for the interfaces of a router is normally a precondition for routing protocols to work. Network designers consider link capabilities, connectivity, geography, available address blocks and expected traffic when they pick a topology and the matching interface configuration.
When the capabilities and connectivity of the links that join routers are well known and stable, that job is straightforward. Without any assumption about link-level connectivity, however, there is no canonical method for deciding what a given interface configuration should be.
Link-level connectivity counts as undetermined when it is unplanned, or when it changes over time. Ad hoc networks are the typical example. Routing protocols for ad hoc networks are deliberately built to detect and maintain paths across the network even across links with undetermined connectivity, on the assumption that the routers' interfaces are configured with IP addresses. This document proposes a model for that configuration, so that routing protocols and data packet forwarding can function.
The scope is deliberately narrow. Routers may need more IP prefixes for applications running on the router itself, or for assignment to attached hosts and networks. For IPv6 those addresses may be global (RFC 3587), Unique-Local (RFC 4193) or Link-Local (RFC 4291); for IPv4 they may be global or private (RFC 1918). Global scope is generally preferred over local scope, though automatic configuration may not always achieve it. The document treats that as a separate problem and concentrates on the addresses and prefixes that routing protocols and forwarding need.
On a normal network, an engineer can work out in advance which router sits where and give each interface a sensible address. On an ad hoc network the link may work one minute and not the next, so no fixed plan exists. This memo fills that gap with two rules that hold up when the topology is unknown.
§4The Subnet Prefix Principle
If the link an interface connects to gives no basis for assuming connectivity to other interfaces, the only addresses that can be assumed to be on link are the addresses of that interface itself. Link-local addresses are assumed to be on link, but the utility of link-local addresses is limited, as described later in the document.
Subnet prefix configuration on such an interface must therefore make no promise of direct, one-hop IP connectivity to addresses other than the interface's own. That gives the first principle: no on-link subnet prefix should be configured on such an interface.
This is a statement about IP reachability only. If layer 2 communication is enabled between a pair of interfaces, IP packet exchange is also enabled between them, even if the IP subnet configuration is absent or different on each side.
The principle works in one direction only. When assumptions can be made about connectivity between interfaces, or about the persistent reachability of some addresses, those assumptions should be taken into account when configuring subnet prefixes, and the matching interfaces may then be given an on-link subnet prefix. The applicability statement makes the same point: the more specific the assumptions available, the more the configuration should reflect them.
An on-link subnet prefix tells the router that a whole range of addresses is one hop away. On a link that might not be there tomorrow, that promise cannot be kept, so no on-link prefix is configured. The addresses can still travel over the link, because that depends on the link layer, not on the prefix.
no on-link subnet prefix should be configured on such an interface.
an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain.§5The Address Uniqueness Principle
Routing protocols differ in how unique the interface addresses they run on must be. Some impose no uniqueness requirement at all. Others require local uniqueness only, or uniqueness within at least the routing domain, the area of the network under one administrative routing authority (RFC 1136).
Protocols that need no unique IP address within the routing domain carry a separate identifier of their own, which could come from the factory or from configuration. Such a protocol does not care what the IP address is.
Configuring an address that is unique within the routing domain satisfies the less strict requirements as well, and it also supports the protocols with the strictest requirements. That gives the second principle: an IP address assigned to an interface that connects to a link with undetermined connectivity properties should be unique, at least within the routing domain.
Some routing protocols need the interface address to be unique across the whole routing area, others do not care. Giving every interface an address that is unique in that area satisfies all of them at once, so that is what the model asks for.
§6The IPv6 and IPv4 Models
The two principles give slightly different guidelines for IPv6 and IPv4, because IPv6 offers something IPv4 does not: an interface can simply be left with no on-link subnet prefix at all. The document calls that a cleaner model.
For IPv6 the rules are that the address on the interface should be unique at least within the routing domain, and that no on-link subnet prefix is configured on the interface. An IPv6 link-local address is assigned to each interface anyway (RFC 4291), but in general link-local addresses are of limited utility on links with undetermined connectivity, because connectivity to neighbours may be constantly changing. Two limitations are named. There is in general no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, although link-local addresses that use an interface identifier of the modified EUI-64 form should be globally unique. And routers cannot forward packets with link-local source or destination addresses to other links, while most of the time routers need to forward packets to and from different links. Autoconfiguration solutions should therefore focus on configuring IP addresses that are not IPv6 link-local.
For IPv4 the rules are similar: the address on the interface should be unique at least within the routing domain, and any subnet prefix configured on the interface should be 32 bits long. A prefix of 32 bits names one address, so it makes no claim about any other address being on link. The use of IPv4 link-local addresses (RFC 3927) should be discouraged for most applications, because the limitations above apply to them too. The IPv4 case is worse: the pool of link-local addresses to choose from is smaller, so there is more reliance on Duplicate Address Detection.
IPv6 and IPv4 get slightly different rules, but both end up making no promise about neighbours. IPv6 simply has no on-link prefix at all. IPv4 has to use a prefix of 32 bits, which names one address and nothing else. Link-local addresses are discouraged in both cases, because a router cannot forward packets that carry them to another link.
| Rule | IPv6 model | IPv4 model |
|---|---|---|
| Address on the interface | Unique at least within the routing domain | Unique at least within the routing domain |
| On-link subnet prefix | None is configured | Any prefix configured must be 32 bits long |
| Link-local addresses | Limited utility; do not forward packets that carry them to another link | Discouraged; smaller pool, so more reliance on Duplicate Address Detection |
§7Security Considerations
The document covers only the address and subnet mask configuration that routing protocols and data packet forwarding need to function. RFC 4593 describes the generic threats to routing protocols, and their applicability is not altered by the presence of interfaces with undetermined connectivity properties. The addressing model described here therefore introduces no new security threats.
There is a caveat. The possible lack of pre-established infrastructure or authority, which the use of interfaces with undetermined connectivity properties allows, may make some of the attacks described in RFC 4593 easier to carry out. In particular, malevolent misconfiguration may be harder to detect and harder to locate.
The rules add no new attack of their own. But a network that has no fixed infrastructure and no clear authority is a softer target, and a router set up wrongly on purpose is harder to spot and trace.