One document matched: draft-bernardos-autoconf-addressing-model-00.txt
AUTOCONF Working Group C. Bernardos
Internet-Draft UC3M
Intended status: Informational R. in 't Velt
Expires: April 22, 2010 TNO
October 19, 2009
Addressing Model for Router Interfaces in Ad Hoc Networks
draft-bernardos-autoconf-addressing-model-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 April 22, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes a practical IP addressing model for
interfaces that take part in router-to-router communications in ad
Bernardos & in 't Velt Expires April 22, 2010 [Page 1]
Internet-Draft autoconf addressing model October 2009
hoc networks.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Addressing model . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. IPv4/IPv6 practical addressing model . . . . . . . . . . . 5
3.3. DAD considerations . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Bernardos & in 't Velt Expires April 22, 2010 [Page 2]
Internet-Draft autoconf addressing model October 2009
1. Introduction
In order to communicate among themselves, ad hoc nodes [RFC2501] need
to configure their network interface(s) with addresses that are valid
within an ad hoc network. Ad hoc nodes may also need to configure
globally routable addresses, in order to communicate with devices on
the Internet. From the IP layer perspective, an ad hoc network
presents itself as a L3 multi-hop network formed over a collection of
links.
This document describes a practical addressing model for ad hoc
networks. It is required that such models do not cause problems for
ad hoc-unaware parts of the system, such as standard applications
running on an ad hoc node or regular Internet nodes attached to the
ad hoc nodes.
2. Terminology
Readers are expected to be familiar with all the terms defined in the
RFC 2501 [RFC2501]. In addition the document makes use of the
following definitions:
Wireless Link
Following [I-D.iab-ip-model-evolution], a "wireless link" in the
IP service model refers to the topological area within which a
packet with an IPv4 TTL or IPv6 Hop Limit of 1 can be delivered.
That is, where no IP-layer forwarding (which entails a TTL/Hop
Limit decrement) occurs between two nodes. Due to the wireless
nature of the link, the topological area is defined by the radio-
range coverage of the wireless technology used, and therefore
links are intermittent, and potentially short-lived.
MANET interface
Any interface over which a MANET protocol is run.
MANET domain
A MANET domain is delimited by a set of MANET routers that run a
common MANET routing protocol and corresponds to its routing
domain.
Attached MANET (domain)
A MANET domain attached to an infrastructure based network (e.g.,
the Internet). The MANET interfaces of routers of an attached
Bernardos & in 't Velt Expires April 22, 2010 [Page 3]
Internet-Draft autoconf addressing model October 2009
MANET should be configured with unique global IP addresses, if
these addresses are somehow exposed beyond the MANET domain.
Non-overlapping prefix
A set of IP prefixes is said to be non-overlapping if the
following condition is met: there does not exist any IP address
that could belong to more than one single IP prefix. For example,
2001:DB8:1:1::/64 and 2001:DB8:1:2::/64 are non-overlapping
prefixes, while 2001:DB8:1::/48 and 2001:DB8:1:2::/64 are not.
3. Addressing model
This section describes a practical IPv4/IPv6 addressing model for ad
hoc networks. We first define the scope of the of the addressing
model, then propose how to practically configure IP on MANET
interfaces. Finally, we provide some considerations on address
uniqueness.
3.1. Scope
This document describes an addressing model for MANET interfaces.
Regular (non-MANET) interfaces are not in the scope of the present
document, and they could be configured using standard mechanisms
(such as SLAAC [RFC4862] or DHCP [RFC2131], [RFC3315]). Note, that
while this document does not concern itself with mechanisms for
obtaining prefixes for the purpose of configuring IP addresses on
nodes reachable via non-MANET interfaces, such mechanisms are
presumed to be in scope for the Autoconf WG.
This document does not place restrictions on the use of IP addresses
configured on MANET interfaces. We assume that these IP addresses
are used by MANET routing protocols. We also assume, that once
routes are in place, these addresses play a role in the forwarding of
user data packets. In particular, it is assumed that these addresses
will be found as next-hop addresses in the routing tables of MANET
routers. This entails the performance of link-layer address
resolution on these addresses. Furthermore, these addresses may be
used as source or destination addresses by end-user applications in
those cases where such applications reside on MANET routers.
This document considers MANET domains for the purposes of IP
configuration. Therefore, when we use the term "MANET" throughout
this document, we are referring to a MANET domain. For example,
local uniqueness refer to uniqueness within the MANET domain.
Globally unique IP addresses MUST be provided for routers of attached
Bernardos & in 't Velt Expires April 22, 2010 [Page 4]
Internet-Draft autoconf addressing model October 2009
MANETs for those cases where these addresses are visible outside the
MANET domain, while only uniqueness within the MANET domain is
required for non-attached MANETs.
This document does not rule out that IP addresses might be configured
by non-autoconf mechanisms (e.g., manually) on MANET interfaces.
3.2. IPv4/IPv6 practical addressing model
This section describes the basic principles for IP addressing for
MANET interfaces, in as much an IP version agnostic manner as
possible.
MANET interfaces of attached MANETs SHOULD be configured with global
IPv6 addresses if these addresses are somehow exposed outside the
MANET domain. For non-attached MANETs, ULAs or global addresses
SHOULD be used.
Since the topology of a mobile ad hoc network is expected to be
frequently changing, MANET interfaces MUST be configured with unique/
non-overlapping prefixes. This principle does not assume any prefix
length. The use of /32 (in the IPv4 case) or /128 (in the IPv6 case)
prefix lengths can be an effective way to ensure that prefixes are
non-overlapping. However, it would be needlessly restrictive to
mandate the use of only these prefix lengths. Ensuring that
configured prefixes on MANET interfaces with non-maximum lengths are
non-overlapping is obviously easier for IPv6 than for IPv4, due to
the larger addressing space.
MANET interfaces MUST also be configured with IPv6 Link-local
addresses (as required by RFC 4861 [RFC4861] and RFC 4291 [RFC4291]).
Two main concerns may arise when considering the use of IPv6 Link-
local addresses:
o Address uniqueness: the event of having two duplicate addresses in
the same link has proved to be very low (EUI64 derived interface
identifiers very rarely collide, since MAC addresses are expected
to be globally unique), and even some mechanisms have been
proposed to reduce the collision probability
[I-D.soto-mobileip-random-iids]. Therefore, in most scenarios it
is safe to assume that the probability of having two or more
duplicated link-local addresses in a MANET is negiglible. For
those scenarios, in which this cannot be safely assumed, we refer
to the DAD considerations of Section 3.3.
o Reachability: connectivity among neighbours in wireless links may
be intermittent and/or short-lived. Therefore, the use of link-
local addresses may lead to reachability issues, since two nodes
Bernardos & in 't Velt Expires April 22, 2010 [Page 5]
Internet-Draft autoconf addressing model October 2009
that were in direct coverage range at one moment, might not be
anymore shortly after. These problems might also arise in wired
networks (nodes going up/down), but it is not the common case.
Having brought to attention these concerns, it is further left to the
designers of MANET routing protocols (and other protocols) to
determine whether link-local addresses can be used in an effective
way.
Fluctuating reachability as discussed above is als of concern to the
data forwarding process in ad hoc networks. This is especially true,
if existing mechanisms for neighbour discovery and address resolution
are to be applied. In order to mitigate these problems, several
solutions may be used, such as (but not limited to): decrease some of
the ND default timer values (specified in RFC 4861 [RFC4861]), such
as REACHABLE_TIME, RETRANS_TIMER, DELAY_FIRST_PROBE_TIME,
MIN_RANDOM_FACTOR, MAX_RANDOM_FACTOR; implement a stronger
interaction between the MANET routing protocols and the ND process,
so the MANET routing protocol helps to keep updated the ND tables.
Finally, if none of these solutions (or alternative ones) may be
implemented, processes running on the MANET routers that need to be
isolated from this problem can decide not to use link-local addresses
for their local communications. Since IPv4 lacks any standardised
unreachability detection mechanism, these considerations about
reachability only concern IPv6.
Configuration and use of IPv4 link-locals on MANET interfaces are not
forbidden. However, while in IPv6, an interface may be
simultaneously configured with a link-local address and with unicast
(global or local) addresses, this is not recommended in IPv4
[RFC3927].
Standard mechanisms for layer-2 address resolution, such as ND or ARP
may be used for addresses configured on MANET interfaces. The use of
ARP requires the configuration of an IPv4 broadcast address on MANET
interfaces. This broadcast address MUST have a wider scope than the
unique, non-overlapping prefix of the IPv4 address on the MANET
interface. (In IPv4-bases MANETs, 255.255.255.255 is often used).
As mentioned before, the use of MANET routing protocols may also be
considered as an alternative method for layer-2 address resolution.
3.3. DAD considerations
This document assumes DAD is disabled by default for the IP addresses
configured on MANET interfaces (this is allowed in RFC 4862
[RFC4862]. For the case of link-local addresses, we assume the
collision probability is negiglible, and therefore it is safe to
avoid the overhead of an active DAD process (which would need to be
Bernardos & in 't Velt Expires April 22, 2010 [Page 6]
Internet-Draft autoconf addressing model October 2009
modified to be run in a MANET domain wide fashion). For the case of
the non-overlapping prefixes, we do not specify how their uniqueness
is ensured (this is out-of-scope of this document and falls in the
solution space).
However, this document does not forbid the use of any DAD mechanism,
if it is required in some certain scenarios. From the point of view
of MANETs, it seems appropriate to consider as well the use of
passive DAD approaches (such as [I-D.weniger-autoconf-pdad-olsr]).
4. IANA Considerations
This document makes no request of IANA.
5. Security Considerations
This document does currently not describe any security
considerations.
6. Acknowledgements
Some of the ideas included in this draft have been proposed in the
AUTOCONF ML by several people. Thanks for all the AUTOCONF WG
participants for the fruitful discussions over these years.
The research of Carlos J. Bernardos leading to these results has
received funding from the European Community's Seventh Framework
Programme (FP7/2007-2013) under grant agreement n. 214994 (CARMEN
project) and also from the Ministry of Science and Innovation of
Spain, under the QUARTET project (TIN2009-13992-C02-01).
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
Bernardos & in 't Velt Expires April 22, 2010 [Page 7]
Internet-Draft autoconf addressing model October 2009
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
7.2. Informative References
[I-D.iab-ip-model-evolution]
Thaler, D., "Evolution of the IP Model",
draft-iab-ip-model-evolution-01 (work in progress),
November 2008.
[I-D.soto-mobileip-random-iids]
Bagnulo, M., Soto, I., and A. Azcorra, "Random generation
of interface identifiers",
draft-soto-mobileip-random-iids-00 (work in progress),
January 2002.
[I-D.weniger-autoconf-pdad-olsr]
Mase, K. and K. Weniger, "PDAD-OLSR: Passive Duplicate
Address Detection for OLSR",
draft-weniger-autoconf-pdad-olsr-01 (work in progress),
June 2006.
[RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999.
Bernardos & in 't Velt Expires April 22, 2010 [Page 8]
Internet-Draft autoconf addressing model October 2009
Authors' Addresses
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Ronald in 't Velt
TNO Information and Communication Technology
Brassersplein 2
Delft 2600 GB
The Netherlands
Phone: +31 15 2857306
Email: Ronald.intVelt@tno.nl
Bernardos & in 't Velt Expires April 22, 2010 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 05:31:51 |