RFC 5889 INFORMATIONAL ADDRESSING · AD HOC · ROUTING

IP Addressing Model in Ad Hoc Networks

How to configure router interface addresses and prefixes when you cannot know who is on the other end of the link.

On rfc-editor.org ↗
PUBLISHED
September 2010
AUTHORS
E. Baccelli, M. Townsley
STREAM
IETF
IPV4 PREFIX LENGTH
32 bits
IPV6 ON-LINK PREFIX
None configured
ADDRESS UNIQUENESS
At least within the routing domain
DOI
10.17487/RFC5889

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
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

AI ELI5

On this page
PROBLEMOn ad hoc networks, link connectivity is unplanned or changes over time, so there is no standard way to decide how to configure IP addresses and subnet prefixes on router interfaces.
MECHANISMThe model says to configure no on-link subnet prefix on such an interface (a 32-bit prefix for IPv4) and to make each address unique at least within the routing domain.
STATUS TODAYThis is guidance in an Informational document, not a standard. It lets routing protocols and forwarding function without promising neighbors that are not guaranteed.

§1The Problem with Undetermined Links

Correct IP addresses and subnet masks on router interfaces are generally a prerequisite for routing protocols to work. When links are well known and stable, the design is straightforward. When connectivity is undetermined, meaning unplanned or time-varying, there is no canonical method. Ad hoc networks are the typical example.

The document gives a model for configuring addresses and prefixes on router interfaces to such links so that routing protocols and data forwarding can function. It deliberately covers only the configuration needed for routing and forwarding. Prefixes for applications on the routers or for attached hosts are treated as a separable problem.

When nobody knows who will be your neighbor from minute to minute, you need simple rules for choosing an address that still work.

§2The Two Principles

The first principle covers subnet prefixes. If a link allows no assumptions about connectivity to other interfaces, the only addresses that can be assumed on-link are the interface's own. So no on-link subnet prefix should be configured on such an interface. If layer 2 communication exists between two interfaces, IP packets can still be exchanged even without matching subnet configuration. If assumptions about connectivity or persistent reachability can be made, they should be considered and an on-link prefix may be used.

The second principle covers addresses. Routing protocols differ in how unique addresses must be: some have no requirement, others need local uniqueness, others need uniqueness within the routing domain. Those with no requirement use a separate identifier inside the protocol. An address unique at least within the routing domain satisfies all of them, so an address on such an interface should be unique, at least within the routing domain.

Do not tell the network that a whole street is right next to you when you cannot be sure. And give yourself a name no one else in the neighborhood has.

§3IPv6 and IPv4 Models

For IPv6, the rules are: the address should be unique at least within the routing domain, and no on-link subnet prefix is configured on the interface. IPv6 makes this clean because it allows leaving the on-link prefix out entirely.

For IPv4, the address should likewise be unique at least within the routing domain, and any subnet prefix configured on the interface should be 32 bits long.

Link-local addresses are of limited use here. There is generally no mechanism to ensure IPv6 link-local addresses are unique across multiple links, though those built from a modified EUI-64 identifier should be globally unique. Routers also cannot forward packets with link-local source or destination addresses to other links, and routers mostly need to forward between links. So autoconfiguration should primarily focus on addresses that are not link-local. IPv4 link-local addresses (RFC 3927) should be discouraged for most applications for the same reasons, made worse by the smaller pool and greater reliance on Duplicate Address Detection.

For the newer address style, just leave out the neighborhood size. For the older style, say you are a neighborhood of exactly one house. Skip the addresses that only work on one street.

ADDRESSING RULES FOR LINKS WITH UNDETERMINED CONNECTIVITY
ProtocolAddressOn-link prefix
IPv6Unique at least within the routing domainNone configured
IPv4Unique at least within the routing domainIf any, 32 bits long

§4Security Considerations

The model is not said to introduce new security threats. The generic routing threats in RFC 4593 still apply. However, the possible lack of pre-established infrastructure or authority on such links may make some of those attacks easier, and malevolent misconfiguration may be harder to detect and locate.

With no central office handing out addresses, it is easier for someone to cheat and harder to catch them.

§5References