One document matched: draft-jelger-autoconf-mla-01.txt
Differences from draft-jelger-autoconf-mla-00.txt
Autoconf Working Group C. Jelger
Internet-Draft University of Basel
Expires: April 8, 2007 October 5, 2006
MANET Local IPv6 Addresses
draft-jelger-autoconf-mla-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 8, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines how Unique Local IPv6 Unicast Addresses (RFC-
4193) can be used in wireless mobile ad hoc networks (MANETs) as
MANET Local IPv6 Addresses (MLAs). MLAs are intended to be used
inside a MANET and are not expected to be routable on the global
Internet. Each MANET router is expected to generate its MLA locally
without any coordination with other MANET routers.
Jelger Expires April 8, 2007 [Page 1]
Internet-Draft MANET Local IPv6 Addresses October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MANET Local IPv6 Addresses (MLAs) . . . . . . . . . . . . . . . 3
3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Address generation . . . . . . . . . . . . . . . . . . . . 4
3.3. Address scope . . . . . . . . . . . . . . . . . . . . . . . 4
4. Host configuration . . . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Jelger Expires April 8, 2007 [Page 2]
Internet-Draft MANET Local IPv6 Addresses October 2006
1. Introduction
This document defines a possible use of Unique Local IPv6 Unicast
Addresses (ULAs)[1] as MANET Local IPv6 Addresses (MLAs) in wireless
mobile ad hoc networks (MANETs). MLAs are intended to be used inside
a MANET and are not expected to be routable on the global Internet.
Each MANET router is expected to generate its MLA locally, i.e.
without any coordination with other MANET routers.
This extends the usage of ULAs to an extreme case where each MANET
router is considered as being a site and subnet [1] by itself. In
this particular case, routing is flat and MANET routers do not share
a network prefix. This loose addressing model allows to use a large
fraction of the upper 64-bit part of IPv6 addresses in order to
create addresses that are sufficiently random to avoid the use of
duplicate address detection schemes for intra-MANET communications.
2. Terminology
This document employs the following terms (partly borrowed from [2]):
Node
Any device (router or host) which implements IP.
MANET Router (MR)
A router that engages in a MANET routing protocol. In certain
scenarios, a MR may forward packets for hosts attached to it.
Host
Any node that is not a router, i.e. it does not forward
packets addressed to others.
3. MANET Local IPv6 Addresses (MLAs)
3.1. Format
Strictly speaking, MLAs have the same format as ULAs. The only
difference with ULAs is that both the Global ID and Subnet ID fields
are randomly generated: this results in a merged 56-bit field called
the Random ID. To indicate this difference with ULAs, the L bit is
set to 0. Hence in practise ULAs use FD00::/8 and MLAs use FC00::/8.
| 8 bits | 56 bits | 64 bits |
+----------+------------------------+----------------------------+
| Prefix | Random ID | Interface ID |
+----------+------------------------+----------------------------+
Jelger Expires April 8, 2007 [Page 3]
Internet-Draft MANET Local IPv6 Addresses October 2006
Where:
Prefix FC00::/8 prefix to identify MANET Local
addresses. (L bit of ULAs is set to 0).
Random ID 56-bit random identifier used to create a
globally unique address.
Interface ID 64-bit Interface ID as defined in [3].
3.2. Address generation
To create an MLA for a given physical interface, a MANET router
locally generates its Random ID in a random manner. The Random ID is
used in addition to the Interface ID in order to create an address
with a very high probability of uniqueness. Using 56 bits gives
around 7.2e+16 possible values for the Random ID, hence drastically
reducing the probability of an address collision if two routers
having the same Interface ID generate the same Random ID.
The probability of an address collision is further reduced by the use
of EUI-64 identifiers as Interface IDs. EUI-64 that derive from
EUI-48 (e.g. IEEE 802 48-bit MAC addresses) are indeed expected to
be globally unique, while randomly generated identifiers [4] have an
extremely low collision probability (around 1.8e+19 possible values).
Given the network size currently being considered within the MANET
community (a few hundred nodes), and given the extremely large
randomness of MLAs, a node must not necessarily check whether a
generated MLA is unique. The overhead of performing duplicate
address detection (DAD) greatly superseeds its gain since the
probability of address collisions is extremely low.
Nevertheless, a passive DAD technique could be used in order to
detect address collisions, eventhough such events are very unlikely
to occur. This extra mechanism is however out of the scope of this
document.
3.3. Address scope
As Unique Local IPv6 Unicast Addresses, MANET Local Addresses have a
global scope. However MLAs are not globally routeable, and their use
is restricted inside a MANET. Since there does not exist any
standardized definition of the boundaries of a MANET, we assume that
the use of MLAs is restricted to the set of MANET nodes willing to
route, send, and receive packets using MLAs. This assumes that a
MANET routing protocol should always be willing to route packets
whose source and/or destination addresses are MLAs.
Jelger Expires April 8, 2007 [Page 4]
Internet-Draft MANET Local IPv6 Addresses October 2006
4. Host configuration
If non-router hosts are attached to a MANET router, the MANET router
may advertise the upper 64 bits of its MLA (i.e. a /64 prefix) to its
attached hosts. This can be done via router advertisement messages
as in IPv6 stateless address autoconfiguration [5]. Each host
generates its MLA by appending an interface ID to the MLA prefix
advertised by the MANET router it is attached to. To allow
communications between hosts attached to different MANET routers,
MANET routers MUST exchange and use /64 routes.
Since the hosts attached to a given MANET router may not always be
able to directly communicate one with another (e.g. if they are out
of radio transmision range), the L bit of the Prefix Information
Option of the router advertisement message must be set to 0 to
indicate that the prefix is off-link (see page 30 of [6]). As a
result, hosts receiving the router advertisement message do not
create a subnet route (i.e. a /64 route) for the advertised prefix.
Hence two hosts attached to a given MANET router communicate by
default via the MANET router (as in 802.11 infrastructure mode).
5. Acknowledgements
The idea of using Unique Local IPv6 Addresses as MANET Local
Addresses has been originally discussed with a number of people
including Ryuji Wakikawa, Francisco Ros, Robert Hinden, Brian
Haberman and Guillaume Chelius. Therefore the author of this
document does not claim exclusive credit. Also note that the
formatting of this document is mostly inspired by [1].
Useful comments for version 00 of this draft have been given by Fred
Templin and Joe Macker. When possible, their suggestions have been
included in this new version. In particular, Fred Templin suggested
first that the L bit is set to 0.
6. References
[1] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[2] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad Hoc Network
Architecture", I-D draft-chakeres-manet-arch-00, July 2006.
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[4] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Jelger Expires April 8, 2007 [Page 5]
Internet-Draft MANET Local IPv6 Addresses October 2006
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[6] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
Jelger Expires April 8, 2007 [Page 6]
Internet-Draft MANET Local IPv6 Addresses October 2006
Author's Address
Christophe Jelger
University of Basel
Bernoullistrasse 16
Basel 4056
Switzerland
Phone: +41 61 267 0391
Email: Christophe.Jelger@unibas.ch
Jelger Expires April 8, 2007 [Page 7]
Internet-Draft MANET Local IPv6 Addresses October 2006
Intellectual Property Statement
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 to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jelger Expires April 8, 2007 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-22 21:57:36 |