INTERNET-DRAFT Thomas Clausen
IETF MANET Working Group Emmanuel Baccelli
Expiration: 31 July 2005 LIX, Ecole Polytechnique, France
31 January 2005
Simple MANET Address Autoconfiguration
draft-clausen-manet-address-autoconf-00.txt
Status of this Memo
This document is a submission to the Network Mobility Working Group
of the Internet Engineering Task Force (IETF). Comments should be
submitted to the nemo@ietf.org mailing list.
Distribution of this memo is unlimited.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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.
Abstract
In this draft, a simple autoconfiguration mechanism for MANETs is
developed. The mechanism aims at solving the simple, but common,
problem of one or more new nodes emerging in an existing network. A
solution is proposed, which allows these new nodes to acquire an
address and participate in the network. The method is simple, both
algorithmically and in the requirements to the network. While this is
a partial solution to the general autoconfiguration problem, the
Clausen, Baccelli [Page 1]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 30 January 2005
mechanism described in this draft can satisfy the requirements for a
great number of real-world situations. Though examples are given with
OLSR [1] [11] being the routing protocol in use, nothing prevents the
described mechanisms to work along with other routing protocols.
Clausen, Baccelli [Page 2]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 31 January 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Simple Address Autoconfiguration Solution Overview . . . . . . . 6
4. Local Beaconing . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Aquireing a Local Address . . . . . . . . . . . . . . . . . . . . 9
6. Global Address Assignment . . . . . . . . . . . . . . . . . . . . 10
7. Overhead Estimation . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
13. Security Considerations . . . . . . . . . . . . . . . . . . . . 14
14. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Clausen, Baccelli [Page 3]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 31 January 2005
1. Introduction
A Mobile Ad-hoc NETwork (MANET) is a collection of nodes which are
able to connect on a wireless medium forming an arbitrary and dynamic
network, routing traffic through multi-hop-paths in order to ensure
connectivity between any two nodes in the network. Implicitly herein
is the ability for the network topology to change over time as links
in the network appear and disappear.
In order to enable communication between any two nodes in such a
MANET, a routing protocol is employed. The abstract task of the rout-
ing protocol is to discover the topology (and, as the the network is
dynamic, continuing changes to the topology) to ensure that each node
is able to acquire a recent image of the network topology for con-
structing routes.
An issue, complementary to that of routing, emerges with respect to
bootstrapping of the network. Routing protocols accomplish the task
of discovering paths in a MANET, however a prerequisite to the cor-
rect functioning of routing protocols is that all nodes are identifi-
able by an unique IP-address. Subsequently, a mechanism for assigning
(unique) addresses to MANET nodes is required.
A particularity of MANETs is, that the roles of ``terminal'' and
``network forming node'' (router) are not clearly separate. In prin-
ciple, all nodes may act in both capacities simultaneously. An addi-
tional constraint is, that no assumptions with respect to a preexist-
ing infrastructure can be made. Traditional mechanisms for host auto-
configuration, such as DHCP [7] or ZeroConf [10] or similar mecha-
nisms all assume the presence of a ``server'', which can coordinate
and assign addresses. Further, these mechanisms work on the assump-
tion that direct communication between the ``server'' and all hosts
in the local network is possible. Due to the multi-hop nature of
MANETs, direct communication between an arbitrary host in the network
and (any) server cannot be assumed.
In order to ensure the true autonomy of MANETs, a specific mechanism
-- or adaptation of mechanism -- for address autoconfiguration of
MANETs is required. Such a mechanism is described in the following.
1.1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5].
Clausen, Baccelli [Page 4]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 31 January 2005
Several references are made to the OLSR terminology as described and
employed in [1]. This document uses the following terminology:
- Node: a device capable of participating in a MANET.
- Neighbor Node: A node X is a neighbor node of node Y if node
Y can hear node X.
- Multipoint Relay (MPR): A node which is selected by its
neighbor, node X, to "re-transmit" all the broadcast messages
that it receives from X, provided that the message is not a
duplicate, and that the time to live field of the message is
greater than one.
- Hello Messages: An OLSR node periodically broadcasts a Hello
Message listing its neighbors. These messages are not for-
warded, and serve the purpose of local neighborhood discovery
and maintenance, as well as setting up Multipoint Relays.
- TC Messages: An OLSR node periodically broadcasts a TC Mes-
sage listing its neighborhood link status. These messages are
forwarded throughout the MANET, using MPR flooding, and serve
the purpose of MANET topology discovery and maintenance.
1.2. Applicability
This document describes a simple address autoconfiguration mechanism
aiming at solving a number of real-world situations with one or more
new nodes emerging in an existing network. It is assumed that either
at least one node in the network (typically, this might be a node
providing Internet connectivity) is already configured or that,
absent a previously configured node, an election can be undertaken to
allow one node to self-configure and thereby initiate a network-wide
autoconfiguration as described in this specification.
Even though examples are given with OSLR [1] [11] being the routing
protocol in use, nothing prevents the described mechanism to work
along with other routing protocols.
2. Problem Statement
The issue of autoconfiguration in MANETs is complex since, for a com-
plete solution, issues such as ensuring uniqueness of addresses in
independent MANETs which later merge, must be addressed: independent
MANET must somehow select non-overlapping address-spaces, duplicate
Clausen, Baccelli [Page 5]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 31 January 2005
address detection, conflict resolution -- and the issue of how to
deal with ongoing data streams without loosing data or the require-
ment of specific application behavior.
In this draft, we aim for a simple solution to a simple problem: the
connected case. A common situation occurs, in which an efficient and
simple address autoconfiguration mechanism is desirable and suffi-
cient. This situation is, where a MANET acts as an edge-extension to
the Internet. I.e., nodes are interested in maintaining connection to
each other and to the Internet. The implication is also, that nodes
join or leave the MANET, but do not migrate (alone or in groups)
between different MANETs with the expectation of maintaining connec-
tivity. The topic of nodes migrating between different MANETs may
better be addressed through mechanisms such as NEMO [6].
The mechanism, developed in this draft, is therefore targeted explic-
itly at the connected case described above. While this is a particu-
lar solution to a particular problem, there is indeed a need to
develop a simple and light-weight mechanism efficient for these
stated scenarios.
The address autoconfiguration mechanism in this draft is specified as
an extension to OLSR [1]. However, nothing prevents the mechanism to
be work with other routing protocols as well.
3. Simple Address Autoconfiguration Solution Overview
This section will outline the functioning of the address autoconfigu-
ration mechanism.
The following two terms will be used for the remainder of this draft:
a "new node" is a node which is not yet assigned an address, and thus
not is part of a MANET. An "MANET node" is a node which is assigned
an address and which is part of the network. A "configurating node"
is an MANET node, which is currently assisting a new node in acquire-
ing an address.
- MANET nodes behave as specified by the routing protocol in
use, say OLSR [1]. Additionally, they emit ADDR_BEACON mes-
sages, to signal to new nodes that they may act as configurat-
ing nodes. This is detailed in the following section.
- New nodes do not participate with the routing protocol in use:
for example with OLSR, they do not emit HELLO and TC messages.
However they listen for ADDR_BEACON messages.
Clausen, Baccelli [Page 6]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 31 January 2005
- From among the MANET nodes emitting ADDR_BEACON messages, one
configurating node is selected, and a request for address con-
figuration is issued through an ADDR_CONFIG message. The goal
is for the configurating node to provide the new node with
first a temporary local address, then a permanent global
address.
This process of acquiring a local, temporary address, and the task of
acquiring a global address are detailed in the following sections.
Packet formats are proposed in the case of OLSR.
4. Local Beaconing
Each MANET node, must ensure that it has the ability to provide tem-
porary addresses from a private address space to new nodes. It is
important that, within a region, these temporary addresses are
unique, i.e. that no two new nodes within the same neighborhood are
assigned the same temporary address. In order to ensure this, a pre-
defined address space is allocated to use for ``temporary
addresses''. The task is to ensure that this address space is
divided, without overlap, between nodes in a region of the network:
- Each MANET node will, independently, select a continuous
address sequence from the address space allocated for ``tempo-
rary addresses''.
- Each MANET node will signal, with periodic ADDR_BEACON mes-
sages, this selected sequence. ADDR_BEACON messages are trans-
mitted to neighbor nodes only, i.e. are not forwarded.
- Each node will record the address sequences, selected by all
its neighbor nodes.
If, upon receiving an ADDR_BEACON message, a node detects that there is
a conflicting address sequence selection, arbitration must happen. In
this case:
- If no nodes in the conflict are acting as configurating nodes,
arbitration is carried out simply by having the conflicting
node with the lowest ID (IP-address) select a new, unused
address-sequence.
- If one or more conflicting nodes are acting as configurating
node(s), arbitration must aim at allowing ongoing configura-
tion sessions to complete.
Clausen, Baccelli [Page 7]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 31 January 2005
In order to accommodate this, all configuration nodes ``narrow'' their
selected address-sequence to contain only the address(es) which are cur-
rently assigned to new nodes. This is included in the next ADDR_BEACON.
Nodes which are not currently acting as configuration nodes, select non-
conflicting address sequences. If a conflict between two configurating
nodes remains, the node which has the lowest ID (IP address) must yield.
If OLSR is the routing protocol in use, the ADDR_BEACON message can use
the format specified in the following figure. [1] specifies the values
of Message Size, Originator Address, Message Sequence Number and Vtime.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADDR_BEACON | Vtime | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Sequence Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Sequence Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Currently Used Addresses :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In case of ``narrowing down'' the address-sequence to only currently
used addresses, the ``Address Sequence Start'' and ``Address Sequence
Stop'' are both set to zero.
Each node will periodically send ADDR_BEACON messages, listing both its
address sequence and the addresses which are currently in use. In case
of a conflict, a recipient node can detect if the node with which it is
conflicting is active as configurating node. If both nodes are active as
configurating nodes, the nodes can detect a conflict in the addresses
actually selected.
If OLSR is the routing protocol in use, ADDR_BEACON messages are trans-
mitted piggybacked in the same OLSR packet as OLSR HELLO messages.
Clausen, Baccelli [Page 8]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 31 January 2005
5. Aquireing a Local Address
The first task of a new node is to associate itself with a MANET
node. Thus, the new node listens for ADDR_BEACON messages and selects
one ``configurating node''. An ADDR_CONFIG message is then created
and transmitted, in order to request address configuration from the
selected configurating node. Absent an IP address, the MAC address of
the new node must be included, in order to uniquely identify the new
node.
Upon receiving an ADDR_CONFIG message, the configurating node assigns
a local address to the new node, and signals this assignment through
another ADDR_CONFIG message. Additionally, the configurating node
marks the assigned address as ``used'' in its ADDR_BEACON messages.
Upon receiving a local address through an ADDR_CONFIG message, the
new node can slowly start participating locally with the routing pro-
tocol in use. For example, if OLSR is used, it can start sending
HELLO messages, including only the configurating node as neighbor.
The goal is to allow the new and configurating node to track each
other (i.e. it allows both nodes to ``reset'', should the link disap-
pear before a global address was assigned to the new node), while not
causing the new node to be advertised to the network. Advertising a
node with a non-unique address might lead to data loss, routing loops
etc.
If a new node does not receive an ADDR_CONFIG reply, it may either
(i) retransmit the ADDR_CONFIG to the same configurating node, or
(ii) give up and select an alternative configuration node. Absent the
local participation of the new node in the routing protocol (i.e.
with OLSR, the HELLO message exchange described above) the configu-
rating node may (i) retransmit its ADDR_CONFIG reply, or (ii) give
up, in which case any temporarilly assigned addresses will be
reclaimed.
If OLSR is the routing protocol in use, the ADDR_CONFIG message can
use the format specified in following figure. [1] specifies the val-
ues of Message Size, Originator Address, Message Sequence Number and
Vtime.
Clausen, Baccelli [Page 9]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 31 January 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADDR_CONFIG | Vtime | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Configurating Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: MAC Addresses :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Local Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Global Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the ``Assigned Local Address'', ``Assigned Global Address'' and
``Originator Address'' fields are all set to zero, the ADDR_CONFIG
message is a request to the ``Configurating Node'' to perform local
address assignment.
If the ``Assigned Local Address'' is non-zero (i.e. contains an
actual address) and ``Originator Address'' is non-zero, but the
``Assigned Global Address'' field is set to zero, the ADDR_CONFIG
message is an assignment of a temporary local address. I.e. this is
the reply to a new node, generated by a configurating node.
The ``Assigned Global Address'' field is discussed in the next sec-
tion.
6. Global Address Assignment
When local participation of the new node in the routing protocol has
started (i.e. with OLSR, the HELLO message exchange commences between
the new and configurating node), local address assignment is com-
pleted, and the task of acquireing a global address can commence. The
configurating node is in charge of acting on behalf of the new node,
with respect to acquireing this global address. Since the configurat-
ing node is already part of the MANET, a multitude of different mech-
anisms can be employed. One such mechanism for acquiring a global
address would be for the configurating node to act as a modified DHCP
Clausen, Baccelli [Page 10]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 31 January 2005
proxy [8] and transmit a request to an existing DHCP server in the
network.
Another option would be to consult the nodes' topology table. This
table (in a relatively stable state) contains all destinations (thus
addresses) of the network. The configurating node can thus pick a
non-used address and assign to the new node. In that case, in order
to prevent duplicate address assignment, the configurating node
advertises the selected address to the MANET. If a node detects that
its address is being re-used, it can signal the conflict to the orig-
inator of the ``offending'' advertisement.
If OLSR is the routing protocol in use, the configurating node
includes the selected address in a few TCs. If a node receives a TC
containing its own address (or an address, which the node has claimed
for a new node) AND if the originator of the message is not the node
itself nor an MPR of the node, a duplicate address assignment is
detected. The detecting node can then communicate this to the origi-
nator of the offending TC, with the purpose of resolving the con-
flict.
Once the configurating node has acquired a globally unique address,
it is assigned to the new node through an ADDR_CONFIG message, con-
taining the same ``Assigned Local Address'' and ``Originator
Address'' as before, but with a non-zero address in the ``Assigned
Global Address'' field. This is then the ticket for the new node to
participate fully in the MANET.
The configurating node will continue to transmit this ADDR_CONFIG
message periodically until it detects that the new node has taken it
into account. With OLSR, thw configurating node can detect this
either when the HELLO messages from the new node's assigned local
address cease, or when an ADDR_CONFIG message from the new node is
received, listing the new nodes global address in both the originator
field and the ``Assigned Global Address'' field, the ``Assigned Local
Address'' and the ``MAC address'' fields.
7. Overhead Estimation
The overhead incurring from the mechanism specified in this draft
comes from primarily three sources: (i) periodic beaconing of
ADDR_BEACON messages, (ii) address request/replies through ADDRmes-
sages, and (iii) discovery of a globally unique address.
ADDR_BEACON messages and ADDR_CONFIG messages are local, i.e. no
flooding operations incur. ADDR_CONFIG messages are furthermore only
Clausen, Baccelli [Page 11]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 31 January 2005
transmitted while nodes are being configured, and are of limited size
(24 bytes + size of MAC address). Each configuration cycle incurs 4
messages. The overall overhead, incurred through this procedure, is
therfore negligible.
With OLSR, ADDR_BEACON messages are transmitted in the same OLSR
packets as OLSR HELLO messages (MTU permitting), thus the number of
transmissions required remains constant as compared to OLSR. Except
when an node configuration is ongoing, the additional overhead
incurred from ADDR_BEACON amounts to 20 bytes.
on the other hand, the discovery of a globally unique message depends
on the mechanism employed. Assuming a decentralized mechanism, where
an unused address is picked from the topology table and is probed
through including this address in a TC emission, the additional over-
head per TC message for that node is 4 bytes. This is offset by the
fact that if an address is assigned to the new node, topological
information is already present in the network, allowing the node
immediate participation.
8. Acknowledgements
The authors would like to thank Hitachi Labs Europe for their support.
9. Authors' Addresses
Thomas Heide Clausen,
Project PCRI
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: T.Clausen@computer.org
Emmanuel Baccelli
HITACHI Labs Europe/ Project PCRI,
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Clausen, Baccelli [Page 12]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 31 January 2005
Email: Emmanuel.Baccelli@inria.fr
10. References
[1] T. Clausen, P. Jacquet, Optimized Link State Routing Protocol.
Request for Comments (Experimental) 3626, Internet Engineering Task
Force, October 2003.
[2] T. Clausen, G. Hansen, L. Christensen, G. Behrmann, The Optimized
Link State Routing Protocol - Evaluation Through Experiments and
Simulation. Proceedings of the Fourth Wireless Personal Multimedia
Communications, September 2001.
[3] S. Bradner. Key words for use in RFCs to Indicate Requirement Lev-
els. Request for Comments (Best Current Practice) 2119, Internet
Engineering Task Force, March 1997.
[4] R. Wakikawa et al. Global Connectivity for IPv6 Mobile Ad Hoc Net-
works (work in progress). Internet Draft (draft-wakikawa-manet-
globalv6-03.txt), Internet Engineering Task Force, October 2003.
[5] T. Clausen, P. Jacquet, L. Viennot, Comparative study of routing
protocols for mobile ad-hoc networks. Proceedings of IFIP Med-Hoc-
Net 2002, September 2002.
[6] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Nemo
Basic Support Protocol (work in progress). Internet Draft (draft-
ietf-nemo-basic-support-02), Internet Engineering Task Force,
December 2003.
[7] R. Droms, Dynamic host configuration protocol, RFC 2131, Internet
Engineering Task Force, March 1997.
[8] M. Patrick, Dhcp Relay Agent Information Option, RFC 3046, Internet
Engineering Task Force, January 2001.
[9] A. Qayyum, L. Viennot, A. Laouiti, Multipoint relaying: An Efficient
Technique for Flooding in Mobile
Wireless Networks. INRIA Research Report RR-3898, Project Hiper-
com, March 2000.
[10] A. Williams, Requirements for Automatic Configuration of IP Hosts.
Internet Draft, draft-ietf-zeroconf-reqts-12.txt, September 2002,
Work in progress.
[11] E. Baccelli, T. Clausen, A Simple Address Autoconfiguration Mecha-
nism for OLSR, IEEE International Symposium on Circuits and Sys-
tems, ISCAS 2005.
Clausen, Baccelli [Page 13]
INTERNET-DRAFT Simple MANET Address Autoconfiguration 31 January 2005
11. Changes
This is the initial version of this specification.
12. IANA Considerations
This document does currently not specify IANA considerations.
13. Security Considerations
This document does not specify any security considerations.
14. Copyright
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 INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.