One document matched: draft-jeong-manet-addr-autoconf-reqts-03.txt
Differences from draft-jeong-manet-addr-autoconf-reqts-02.txt
Internet-Draft J. Jeong (ed.)
ETRI/University of Minnesota
Expires: April 2005 23 October 2004
Requirements for Ad Hoc IP Address Autoconfiguration
draft-jeong-manet-addr-autoconf-reqts-03.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which we become aware will be disclosed, in accordance
with RFC3668.
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, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Ad hoc network has no built-in infra-structure for communication
among mobile nodes and operates in a stand-alone fashion, or may be
connected to the public Internet. All the nodes in ad hoc network
have the capability to maintain all the resources of the network in a
distributed fashion. One of the most important resources is the set
Jeong, et al. Expires - April 2005 [Page 1]
Internet-Draft MANET Address Autoconf Requirements October 2004
of IP addresses configured with an addressing scheme. When a new
node joins a network, it has to be assigned a unique IP address as
part of its initialization. Since ad hoc network's topology may
change unpredictably, it is important to provide a resilient method
for providing IP address autoconfiguration. This document specifies
the requirements for IP address autoconfiguration in ad hoc networks
which have dynamic network topology.
Conventions used in this document
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 [3].
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. Scenarios......................................................3
3.1. Join and Departure of Mobile Nodes........................3
3.2. Network Partitioning and Merging..........................4
3.3. Internet Connectivity.....................................4
4. Requirements for Ad Hoc IP Address Autoconfiguration...........5
5. IPv6 Considerations............................................6
6. Security Considerations........................................7
7. Open Issues....................................................7
8. Acknowledgements...............................................8
9. Normative References...........................................8
10. Informative References........................................8
11. Authors' Addresses............................................9
12. Intellectual Property Statement..............................10
Full Copyright Statement.........................................11
Acknowledgement..................................................11
1. Introduction
IP address configuration is a prerequisite for all the IP networking.
In ad hoc networks, such configuration should be performed in every
mobile node, either manually or automatically. For convenience sake,
automatic configuration is needed in mobile ad hoc network [4].
In ad hoc networks, having dynamic network topology and being multi-
hop, the current automatic address configuration schemes used in the
Internet are difficult to adopt, such as DHCP and IPv6 stateless
address autoconfiguration. Also, mobile ad hoc network is an
unadministered network where there exists no network administrator
who provides network configuration information to users. In this
Jeong, et al. Expires - April 2005 [Page 2]
Internet-Draft MANET Address Autoconf Requirements October 2004
environment, mobile node should be able to self-configure its IP
address.
This document specifies the requirements for IP address
autoconfiguration, considering mobile ad hoc network where there
happen the network partitioning and merging very often. Also, it
considers the global connectivity between the mobile ad hoc network
and Internet.
2. Terminology
Two new terms are defined below:
Mobile Ad Hoc Network (MANET) A network where mobile nodes can
communicate with one another without
preexisting communication
infrastructure such as base station
or access point.
Autoconfiguration (Autoconf) Automatic configuration or
self-configuration.
3. Scenarios
There are the scenarios that should be considered in ad hoc IP
address autoconfiguration. Address autoconf protocol needs to deal
with the following aspects of the ad hoc environment.
3.1. Join and Departure of Mobile Nodes
When a mobile node joins a new MANET, an unused IP address is
allocated to or configured in the mobile node. When the mobile node
leaves the MANET, its address may become free for another.
Requirements:
o Address autoconf protocol MUST support timely autoconfiguration of
IP address for a mobile node.
o Address autoconf protocol MAY support mechanisms to probe
whether a mobile node moves into another MANET.
o Mobile nodes using address autoconf protocol MUST validate
allocated IP addresses when powering up or rebooting.
o Mobile nodes using address autoconf protocol MAY validate
allocated IP addresses when moving into a new network.
Jeong, et al. Expires - April 2005 [Page 3]
Internet-Draft MANET Address Autoconf Requirements October 2004
Implication:
o The information needed to autoconfigure IP address must be
collected or predefined in the MANET.
3.2. Network Partitioning and Merging
Inevitably, a single MANET will be divided into two or more MANET
partitions. Also, these two or more MANET partitions, using the same
address autoconf protocol, will be connected together, creating a
single merged MANET. Prior to the merging, each partition has
independently allocated or configured addresses. After merging, two
nodes in the merged network may end up using the same address, thus
potentially creating address conflict.
Therefore, this network merging must be perceived by mobile node. If
address conflicts exist, they should be resolved.
Implication:
o The detection and resolution of address conflicts are the
indispensable part of address autoconf protocol operation.
Requirements:
o Ad hoc address autoconf protocol MUST detect and resolve address
conflicts in a timely manner and on an ongoing basis.
o Ad hoc address autoconf protocol MUST allow conflicted address
replaced with another.
o Ad hoc address autoconf protocol SHOULD minimize the damage, such
as loss of delivered packets, due to address replacement.
o Addresses SHOULD be allocated or autoconfigured in a way that
minimizes the probability that two or more nodes will have the
same address.
o In order to detect duplicate addresses, ad hoc address autoconf
protocol MAY get the aid of ad hoc routing protocol.
Through address autoconf protocol that detects and resolves the
conflicts on an ongoing basis, mobile nodes will benefit from
preventing misrouting due to duplicate addresses, and can be provided
consistent routing.
3.3. Internet Connectivity
Jeong, et al. Expires - April 2005 [Page 4]
Internet-Draft MANET Address Autoconf Requirements October 2004
A mobile node can want to communicate with a node placed in the
Internet. In such a case, an Internet gateway providing the Internet
connectivity can exist in the MANET [5].
Requirements:
o MANET SHOULD allow configuration of zero or more gateways for the
global connectivity to the Internet.
o Mobile node that desires Internet connectivity MAY have a globally
routable IP address.
Implication:
o For host DNS name resolution, DNS information, such as the address
of recursive DNS server, should be delivered together with gateway
information.
4. Requirements for Ad Hoc IP Address Autoconfiguration
Ad hoc IP address autoconfiguration always includes the configuration
of an IP address and netmask (or prefix information in IPv6); it may
include some routing information (such as default route or Internet
gateway), considering the global connectivity to the Internet. IP
address autoconfiguration must take place before an IP packet can be
sent from one node to another. This section requires that sufficient
information be provided by an ad hoc address autoconf protocol to
allow IP packets to be sent to a unicast destination IP address
within a connected MANET partition, consisting of multi hops.
Requirements: An ad hoc address autoconf protocol
o MUST configure an appropriate netmask or prefix information.
o MUST allocate or autoconfigure unique IP addresses within a
connected MANET partition.
o MAY allow configuration of zero or more gateways for the global
connectivity to the Internet.
The following requirements are derived from applying Section 3.1 and
Section 3.2 to IP interface configuration.
Requirements: An ad hoc address autoconf protocol
o MUST be capable of providing IP address in a reasonable delay.
o MUST be capable of discovering whether an IP address is currently
Jeong, et al. Expires - April 2005 [Page 5]
Internet-Draft MANET Address Autoconf Requirements October 2004
in use.
o MUST detect and resolve IP address conflicts in a timely manner
and on an ongoing basis.
o MUST timely validate autoconfigured IP addresses when powering up
or rebooting.
o MAY timely validate autoconfigured IP addresses when moving into a
new network.
o SHOULD be able to process the address conflict due to manual
address configuration.
o SHOULD minimize the influence of autoconf traffic on the ongoing
MANET communication performance.
o MAY get the aid of ad hoc routing protocol so as to detect
duplicate addresses.
o SHOULD minimize the modification of existing MANET routing
protocol.
o MAY get the aid of ad hoc routing protocol so as to minimize
the probability that two or more nodes will have the same address.
o When MANET partitions merge, ad hoc address autoconf protocol
SHOULD be performed in the way it avoids congestion caused by
messages sent for the purpose of duplicate address detection.
o SHOULD minimize the damage, such as loss of delivered packets,
due to address replacement for supporting the survivability
of upper-layer sessions, such as TCP.
o SHOULD allocate IP addresses to mobile nodes in a way that
minimizes the probability that two or more nodes will have the
same address.
o The reclamation of addresses unused any more MAY be considered.
An IP address is assigned only for the duration the node stays in
the network. When the node departs the network, its IP address
MAY become available for assignment to other nodes. In this case,
address autoconf protocol SHOULD NOT immediately reuse the
released IP addresses as soon as they become available, in order
to reduce address conflicts.
5. IPv6 Considerations
Jeong, et al. Expires - April 2005 [Page 6]
Internet-Draft MANET Address Autoconf Requirements October 2004
IPv6 provides a mechanism that allows a host to generate a link-local
IP address Autoconfiguration [6][7]. Thus, this mechanism can be
extended to be suitable for MANET [8] or another can be redesigned
separately [9][10]. Also, it is necessary to discuss how to use IPv6
link-local address in a MANET which is logically one subnet.
6. Security Considerations
Ad hoc IP address autoconf protocol MUST NOT be any less secure than
current IETF-Standard protocols related to IP address
autoconfiguration.
Because of their lack of infrastructure and their strong mobility,
mobile ad hoc networks are vulnerable to lots of security attacks.
Especially, address autoconf protocol is likely to be a good target
for attackers. For example, it can be the victim of Denial of
Service attacks in which a malicious node monopolizes all the
addresses or sends the response messages to create address conflicts
in the network. Consequently, an ad hoc IP address autoconf protocol
SHOULD, as much as possible, prevent such attacks.
Requirements: An ad hoc address autoconf protocol
o SHOULD prevent malicious nodes from monopolizing all addresses of
a network.
o SHOULD prevent malicious nodes from voluntarily creating IP
conflicts.
o SHOULD be able to identify nodes which belong to the network.
o SHOULD make sure that only authorized nodes are configured and
granted access to network resources.
Implication:
o A node SHOULD be able to prove at every moment, its membership of
the network.
7. Open Issues
There are some open issues about ad hoc address autoconfiguration as
follows:
o Is there any need to categorize requirements into some classes?
Most of the ad hoc address autoconf protocols proposed until now
can be categorized into two classes: a) Stateless address
autoconf protocol and b) Stateful address autoconf protocol.
Jeong, et al. Expires - April 2005 [Page 7]
Internet-Draft MANET Address Autoconf Requirements October 2004
We need to discuss if we should specify the respective
requirements according to each class.
o Should we make ad hoc address autoconf protocol completely
independent of ad hoc routing protocol or able to get the aid of
ad hoc routing protocol? We can use ad hoc routing protocol to
detect address conflict.
o Should we consider address conflict in the overlapped MANETs with
two or more ad hoc routing protocols?
o How can we design address autoconfiguration mechanism efficiently
when ad hoc networks are connected to the infrastructured
networks, such as the Internet?
o Should we consider the coexistence of the address autoconf
protocol using authentication mechanism and that not using
authentication mechanism?
8. Acknowledgements
This draft has greatly benefited from inputs by Charles E. Perkins
and Kilian Weniger. The authors appreciate their contribution.
9. Normative References
[1] S. Bradner, "Intellectual Property Rights in IETF Technology",
RFC 3668, February 2004.
[2] S. Bradner, "IETF Rights in Contributions", RFC 3667,
February 2004.
[3] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
10. Informative References
[4] A. Williams, "Requirements for Automatic Configuration of IP
Hosts", draft-ietf-zeroconf-reqts-12.txt, September 2002, Work
in Progress.
[5] R. Wakikawa et al., "Global connectivity for IPv6 Mobile Ad
Hoc Networks", draft-wakikawa-manet-globalv6-03.txt, November
2002, Work in Progress.
[6] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for
IP version 6", RFC 2461, December 1998.
Jeong, et al. Expires - April 2005 [Page 8]
Internet-Draft MANET Address Autoconf Requirements October 2004
[7] S. Thomson and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[8] C. Perkins et al., "IP Address Autoconfiguration for Ad Hoc
Networks", draft-ietf-manet-autoconf-01.txt, November 2001, Work
in Progress.
[9] J. Jeong et al., "Ad Hoc IP Address Autoconfiguration",
draft-jeong-adhoc-ip-addr-autoconf-03.txt, July 2004, Work in
Progress.
[10] J. Jeong et al., "Ad Hoc IP Address Autoconfiguration for AODV",
draft-jeong-manet-aodv-addr-autoconf-01.txt, July 2004, Work in
Progress.
11. Authors' Addresses
Jaehoon Paul Jeong, Editor
ETRI/University of Minnesota at Twin Cities
117 Pleasant Street SE
Minneapolis, MN 55455
USA
Phone: +1 651 587 7774
EMail: jjeong@cs.umn.edu
Jung-Soo Park
ETRI / PEC
161 Gajeong-dong, Yuseong-gu
Daejeon 305-350
Korea
Phone: +82 42 860 6514
EMail: pjs@etri.re.kr
Kenichi Mase
Niigata University
2-8050 Ikarashi,
Niigata-shi, 950-2181
Japan
Phone: +81 25 262 7446
EMail: mase@ie.niigata-u.ac.jp
Youn-Hee Han
Samsung Advanced Institute of Technology
111, Suwon 440-600
Jeong, et al. Expires - April 2005 [Page 9]
Internet-Draft MANET Address Autoconf Requirements October 2004
Korea
Phone: +82 31 280 9577
EMail: yhhan@sait.samsung.co.kr
Badis Hakim
LRI Laboratory
University of Paris-XI
91405 Orsay cedex
France
Phone: 01 69 15 65 91
EMail: Hakim.Badis@lri.fr
Jean-Marie Orset
Institut National des Telecommunications
9, rue Charles Fourier
91 011 Evry
France
Phone: 01 60 76 44 75
EMail: jean-marie.orset@int-evry.fr
12. Intellectual Property Statement
The following intellectual property notice is copied from RFC3668,
Section 5.
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
Jeong, et al. Expires - April 2005 [Page 10]
Internet-Draft MANET Address Autoconf Requirements October 2004
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Full Copyright Statement
The following copyright notice is copied from RFC3667, Section 5.4.
It describes the applicable copyright for this document.
Copyright (C) The Internet Society (2004). 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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jeong, et al. Expires - April 2005 [Page 11] | PAFTECH AB 2003-2026 | 2026-04-23 04:11:29 |