draft-ietf-autoconf-statement-03.txt   draft-ietf-autoconf-statement-04.txt 
MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.)
Internet-Draft INRIA Internet-Draft INRIA
Expires: August 3, 2008 K. Mase Expires: August 28, 2008 February 25, 2008
Niigata University
S. Ruffino
Telecom Italia
S. Singh
Samsung
January 31, 2008
Address Autoconfiguration for MANET: Terminology and Problem Statement Address Autoconfiguration for MANET: Terminology and Problem Statement
draft-ietf-autoconf-statement-03 draft-ietf-autoconf-statement-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 3, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document states the problems pertaining to automatic IPv6 This document states the problems pertaining to automatic IPv6
address configuration and prefix allocation in MANETs. address configuration and prefix allocation in MANETs.
This draft currently contains terminology, target scenarios and goals
for MANET autoconfiguration. Future versions of this document will
also review the applicability of existing IPv6 address
autoconfiguration and prefix allocation mechanisms, and security
considerations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MANET Categories . . . . . . . . . . . . . . . . . . . . . . . 5 3. MANET Categories . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Subordinate MANET . . . . . . . . . . . . . . . . . . . . 5 3.1. Subordinate MANET . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Scenarios of Subordinate MANETs . . . . . . . . . . . 6 3.1.1. Scenarios of Subordinate MANETs . . . . . . . . . . . 6
3.2. Autonomous MANET . . . . . . . . . . . . . . . . . . . . . 6 3.2. Autonomous MANET . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Scenarios of Autonomous MANETs . . . . . . . . . . . . 7 3.2.1. Scenarios of Autonomous MANETs . . . . . . . . . . . . 7
4. MANET Autoconfiguration Goals . . . . . . . . . . . . . . . . 8 4. MANET Autoconfiguration Goals . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Applicability of standard configuration solutions . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5.1. Applicability of DHCP . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1. Issues with DHCP Fundamental Assumptions . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 5.1.2. What DHCP Can and Cannot Do in MANETs . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 5.2. Applicability of SLAAC/NDP . . . . . . . . . . . . . . . . 10
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Issues with SLAAC/NDP Fundamental Assumptions . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.2. What SLAAC/NDP Can and Cannot Do in MANETs . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 15 5.3. Applicability of DHCP-PD . . . . . . . . . . . . . . . . . 11
5.3.1. Issues with DHCP-PD Fundamental Assumptions . . . . . 11
5.3.2. What DHCP-PD Can and Cannot Do in MANETs . . . . . . . 11
6. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Solutions Requirements . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 20
Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
As defined in [1], a MANET is a network composed of MANET routers, As defined in [1], a MANET is a network composed of MANET routers,
each of which has at least one MANET interface. This document states each of which has at least one MANET interface. This document states
the goals of autoconfiguration mechanism(s) for MANETs, with respect the goals of autoconfiguration mechanism(s) for MANETs, with respect
to the necessary parameters for basic IP identification. to the necessary parameters for basic IP identification.
Specifically, this document thus states the requirements for: Specifically, this document thus states the requirements for:
- autoconfiguring MANET interfaces with IPv6 addresses; - autoconfiguring MANET interfaces with IPv6 addresses;
- automatic allocation of IPv6 prefixes to MANET routers. - automatic allocation of IPv6 prefixes to MANET routers.
This draft currently contains terminology, target scenarios and goals
for MANET autoconfiguration. Future versions of this document will
also review the applicability of existing IPv6 address
autoconfiguration and prefix allocation mechanisms, and security
considerations.
2. Terminology 2. Terminology
This document uses the terminology defined in [1], as well as the This document uses the terminology defined in [1], as well as the
following terms : following terms :
External Network - a network connected to the MANET, through an External Network - a network connected to the MANET, through an
interface that is not part of this MANET. interface that is not part of this MANET.
Subordinate MANET - a MANET, which is connected to one or more Subordinate MANET - a MANET, which is connected to one or more
external network(s), and where such external network(s) are external network(s), and where such external network(s) are
skipping to change at page 4, line 26 skipping to change at page 4, line 26
Autonomous MANET - a MANET upon which no external network imposes an Autonomous MANET - a MANET upon which no external network imposes an
addressing hierarchy. addressing hierarchy.
Address autoconfiguration - the process of configuring an interface Address autoconfiguration - the process of configuring an interface
with a given address, using an automatic mechanism (contrary to with a given address, using an automatic mechanism (contrary to
manual configuration). manual configuration).
Prefix allocation - the process of providing a router with authority Prefix allocation - the process of providing a router with authority
over an aggregatable pool of addresses (i.e. a prefix), for the over an aggregatable pool of addresses (i.e. a prefix), for the
purpose of configuring interfaces or other routers. purpose of configuring its interfaces, or other nodes.
Disjoint prefixes - two prefixes are said to be disjoint if and only Disjoint prefixes - two prefixes are said to be disjoint if and only
if their respective address ranges do not overlap. if their respective address ranges do not overlap.
Network merging - the process by which two or more previously Network merging - the process by which two or more previously
disjoint MANETs get connected. disconnected MANETs get connected.
Network partitioning - the process by which a MANET splits into two Network partitioning - the process by which a MANET splits into two
or more disconnected MANETs. or more disconnected MANETs.
3. MANET Categories 3. MANET Categories
IP address autoconfiguration on MANET interfaces and prefix IP address autoconfiguration on MANET interfaces and prefix
allocation for MANET routers may be used in a number of deployment allocation for MANET routers may be used in a number of deployment
scenarios. This section outlines the different types of scenarios scenarios. This section outlines the different types of scenarios
that are to be addressed by solutions for MANET autoconfiguration. that are to be addressed by solutions for MANET autoconfiguration.
Note that solutions should also aim at coping with special cases such
as a MANET transiting from one type of scenario to an other, or such
as routers pre-configured with IP addresses (or prefixes) joining the
MANET.
3.1. Subordinate MANET 3.1. Subordinate MANET
A subordinate MANET, as shown in Fig. 1, is a MANET which is A subordinate MANET, as shown in Fig. 1, is a MANET which is
connected to at least one external network N that imposes a specific connected to at least one external network N that imposes a specific
addressing hierarchy on the MANET. In a subordinate MANET, this addressing hierarchy on the MANET. In a subordinate MANET, this
addressing hierarchy yields the use of specific prefixes for addressing hierarchy yields the use of specific prefixes for
communications between nodes in the MANET and nodes in or across communications between nodes in the MANET and nodes in or across
network N. For instance, in Fig. 1, these prefixes need to be network N. For instance, in Fig. 1, these prefixes need to be
topologically correct, i.e. allocated from within a prefix p::, over topologically correct, i.e. allocated from within a prefix p::, over
which the point of attachment to network N has authority. which the point of attachment to network N has authority.
skipping to change at page 6, line 23 skipping to change at page 6, line 21
Internet, which yields the use of topologically correct IP addresses Internet, which yields the use of topologically correct IP addresses
in order to communicate over the Internet. For instance public in order to communicate over the Internet. For instance public
wireless mesh networks, i.e. scattered fixed WLAN access routers wireless mesh networks, i.e. scattered fixed WLAN access routers
participating in a MANET of mobile users, and acting as border participating in a MANET of mobile users, and acting as border
routers. routers.
Another typical example is the coverage extension of a fixed wide- Another typical example is the coverage extension of a fixed wide-
area wireless network, where one or more MANET router(s) are area wireless network, where one or more MANET router(s) are
connected to the Internet through technologies such as UMTS or WiMAX. connected to the Internet through technologies such as UMTS or WiMAX.
Car-to-car communication networks connected to an external Vehicle communication networks connected to an external
infrastructure may also be understood as an instance of subordinate infrastructure may also be understood as an instance of subordinate
MANET. MANET.
3.2. Autonomous MANET 3.2. Autonomous MANET
Autonomous MANETs are MANETs upon which no external network imposes Autonomous MANETs are MANETs upon which no external network imposes
an addressing hierarchy. This is shown in Fig. 2, as opposed to the an addressing hierarchy. This is shown in Fig. 2, as opposed to the
subordinate MANET category described in Section 3.1. subordinate MANET category described in Section 3.1.
+---+ +---+
skipping to change at page 7, line 31 skipping to change at page 7, line 11
Figure 2: Autonomous MANET. No subordination to an Figure 2: Autonomous MANET. No subordination to an
addressing scheme imposed by an external network. addressing scheme imposed by an external network.
3.2.1. Scenarios of Autonomous MANETs 3.2.1. Scenarios of Autonomous MANETs
This section contains a non-exhaustive list of instances of MANETs This section contains a non-exhaustive list of instances of MANETs
falling in the autonomous category. falling in the autonomous category.
Typical examples of autonomous MANETs are networks set-up in areas Typical examples of autonomous MANETs are networks set-up in areas
where infrastructure is unavailable or inapproriate. For instance, where infrastructure is unavailable or inappropriate. For instance,
car-to-car communication for sharing traffic and safety-related car-to-car communication for sharing traffic and safety-related
information, on-site emergency communication among rescue team information, on-site emergency communication among rescue team
members for disaster recovery, file sharing in conference or class members for disaster recovery, file sharing in conference or class
rooms. rooms.
4. MANET Autoconfiguration Goals 4. MANET Autoconfiguration Goals
The goals of AUTOCONF is to provide autoconfiguration mechanisms The goals of AUTOCONF is to provide autoconfiguration mechanisms
which allow each MANET router to: which allow each MANET router to:
1. configure IPv6 addresses that are unique within the MANET, on 1. configure IPv6 addresses that are unique within the MANET, on
their MANET interface(s). their MANET interface(s).
2. be allocated IPv6 prefixes that are disjoint from prefixes 2. be allocated IPv6 prefixes that are disjoint from prefixes
allocated to other routers within the MANET. allocated to other routers within the MANET.
3. maintain, within the MANET, the uniqueness of configured addresses 3. maintain, within the MANET, the uniqueness of configured addresses
and the disjoint character of allocated prefixes (even in face of and the disjoint character of allocated prefixes (even in case of
network merging). network merging).
4. be allocated topologically correct prefixes, in the subordinate 4. be allocated topologically correct prefixes, in the subordinate
MANET scenario. MANET scenario.
5. Security Considerations 5. Applicability of standard configuration solutions
This document does not currently introduce security considerations This section reviews the applicability of existing standard protocols
beyond those captured by [1]. for the purposes listed in Section 4. Note that MANET routers are
assumed to also run these standard protocols as usual over non-MANET
interfaces, if any.
6. IANA Considerations 5.1. Applicability of DHCP
DHCP [4] enables automatic allocation of an IP address to a node by a
DHCP server. A node requiring an IP address contacts a DHCP server
and requests an address. The DHCP server will dynamically assign an
address from a certain pool of addresses, and allocate a so called
''lease'' of that address to the client. The client can then use the
address for a certain time. If the client wants to keep the address
for a longer time, it has to prolong the lease. If the DHCP server
is not on the same link as the DHCP client, it is possible to use one
or more DHCP relay agent to forward the messages to a different
subnet.
5.1.1. Issues with DHCP Fundamental Assumptions
DHCP works on the basic assumption that every node in the MANET can
directly communicate with either (i) the DHCP server, or (ii) a DHCP
relay which can communicate with either the DHCP server or another
relay.
As described in [1], part (i) of this assumption is often wrong in a
MANET, as each node may see a different set of neighboring MANET
nodes. On the other hand, part (ii) of this assumption relies on the
guarantee that the recursion will end at some point (by reaching the
root, i.e. the DHCP server). Because of the dynamics in MANET
topology and MANET membership described in [1], there is no such
assurance in a MANET, as the DHCP server may be unreachable, or a
loop may have appeared along the path.
Moreover, DHCP works with the assumption that either (a) there is a
unique DHCP server in the network, or (b) if there are several DHCP
servers in the network, they are manually configured accordingly.
Because of the dynamics in MANET membership described in [1], there
is no such assurance in a MANET, as topology changes may produce a
situation where several servers with conflicting configuration
parameters (e.g. managing non-disjoint pools of local addresses)
become part of the same MANET. Servers may thus require dynamic
(re)configuration.
Similarly, DHCP works with the assumption that should there be DHCP
relays, they benefit from appropriate manual configuration. Because
of the dynamics in MANET membership and topology described in [1],
there is no such assurance in a MANET. Configuration may not remain
appropriate over time, and relays may thus require dynamic
(re)configuration.
5.1.2. What DHCP Can and Cannot Do in MANETs
DHCP "as is" could be used to some extent for address configuration
purposes (goal 1, listed in Section 4). However DHCP's applicability
in this context is limited. Indeed, if the topology is or becomes
such that a MANET router does not have access to a DHCP server
directly nor through a relay, DHCP is not operational.
DHCP "as is" could also be used to some extent for uniqueness
maintenance purposes (goal 3, listed in Section 4). However DHCP's
applicability in this context is limited. Since different DHCP
servers will not automatically check the disjoint character of the
pools of addresses they provide leases from, if the topology is or
becomes such that several DHCP servers with conflicting configuration
lease addresses in the same MANET, there is no guarantee that
configured addresses will indeed be unique.
5.2. Applicability of SLAAC/NDP
Stateless Address Autoconfiguration (SLAAC [5]) enables automatic
configuration of an IP address to a host without contacting any kind
of server. A host first constructs a tentative IPv6 address by
attaching its host identifier (in most cases its MAC address) to the
well-known link-local prefix. It then operates duplicate address
detection, that verifies that no other host on the link has the same
address by broadcasting NDP messages [3]. If the address is not
unique, the autoconfiguration process will abort. Upon a successful
address uniqueness test, a host may request a prefix from any router
on the link by an exchange of NDP messages. It will again attach its
host identifier to that router prefix and repeats the address
uniqueness test sequence.
5.2.1. Issues with SLAAC/NDP Fundamental Assumptions
SLAAC relies on NDP signalling, which works on the basic assumption
that each node in the MANET can communicate directly with every other
node in the MANET, i.e. all the nodes are connected to a single
multicast-enabled link. As described in [1], this assumption is
often wrong in a MANET, as each node may see a different set of
neighboring MANET nodes.
5.2.2. What SLAAC/NDP Can and Cannot Do in MANETs
SLAAC "as is" could be used to some extent for address configuration
and uniqueness maintenance purposes (goal 1 and 3, listed in
Section 4), for instance when no DHCP server is available. However
SLAAC's applicability in this context is limited, since NDP messages
are not relayed beyond the ''link'' (or in MANET terms, beyond the
first hop). If topology is or becomes such that the MANET is not
contained in a single hop, there is no guarantee that the configured
addresses will indeed be unique, since signalling will not reach all
the concerned nodes.
5.3. Applicability of DHCP-PD
DCHP-PD [17] is a DHCP option that enables automatic allocation of
IPv6 prefixes to routers using DHCP. A router may request a prefix
allocation from a DHCP server by sending a DHCP request including the
Prefix Delegation option. The server may then delegate a sub-prefix
(i.e. a subset of its address pool) to the router. The DHCP message
containing the Prefix Delegation option may be relayed through one or
more DHCP relays, as per [4].
5.3.1. Issues with DHCP-PD Fundamental Assumptions
DHCP-PD is based on DHCP, and thus encounters the fundamental issues
described in Section 5.1.1, with respect to server reachability, and
dynamic (re)configuration of servers and relays.
5.3.2. What DHCP-PD Can and Cannot Do in MANETs
DHCP-PD "as is" could be used to some extent for prefix allocation
purposes (goals 2 and 4 listed in Section 4) and for uniqueness
maintenance purposes (goal 3, listed in Section 4). However DHCP-
PD's applicability in this context is limited. If topology is or
becomes such that the MANET router cannot communicate with a DHCP
server, DHCP-PD is not operational. Moreover, if topology is or
becomes such that several servers with conflicting configuration
become part of the same MANET, there are no automatic
(re)configuration mechanisms available in order for servers to
dynamically adapt to the situation.
6. Problem Statement
SLAAC, NDP, DHCP and DHCP-PD provide only a partial solution with
respect to the goals listed in Section 4. As explained in
Section 5.1, Section 5.2, and Section 5.3, existing protocols "as is"
cannot deal with the specific dynamic, multi-hop and distributed
nature of MANETs. Additional solutions are thus needed to complete
the goals of MANET IPv6 autoconfiguration.
6.1. Solutions Requirements
The following list presents the requirements for potential IPv6
address autoconfiguration solutions:
R 01. Solutions must configure MANET interfaces with IPv6 addresses
that are unique within the MANET.
R 02. Solutions must configure routers within the same MANET with
disjoint prefixes.
R 03. Solution must work even without a MANET routing protocol.
However, solutions may leverage the presence of routing protocols,
for optimization purposes.
R 04. Solutions must provide a mechanism to prevent and deal with
address or prefix conflicts (due for instance to network merging,
change in MANET membership, preconfiguration or misconfiguration).
R 05. Solutions must be designed taking into account the particular
characteristics of MANETs [1], including their multi-hop nature,
and the potential asymetry of links.
R 06. Solutions must achieve their goal(s) with low control
overhead.
R 07. Solutions must achieve their goal(s) with low delay or
convergence time.
R 08. Solutions must ensure backward compatibility with other
standards defined by the IETF.
R 09. Solutions must not require modifications of existing protocols
on non-MANET interfaces and non-MANET routers.
R 10. Solutions should address security threats considered in
existing IPv6 autoconfiguration mechanisms. In addition,
solutions should address potential MANET-specific threats (see
Section 7).
R 11. Solutions should work in MANETs connected to an external
network via multiple border routers, as well as in MANETs
connected to multiple external networks.
R 12. In the case of subordinate MANETs, solutions should have a
minimal impact on the routing system of the external network(s) to
which a MANET is connected. In particular, this includes the
following:
R 12.1. Solutions should not preclude prefix aggregation at the
edge of the subordinate MANETs.
R 13. Solutions should support transitioning from one MANET scenario
to another (e.g. from subordinate to autonomous or vice-versa).
R 14. Solutions may be designed in a modular way, each module
addressing a specific subset of the requirements or scenarios.
7. Security Considerations
A significant security issue is that of maintaining the
confidentiality and the integrity of some data being exchanged
between communication end-points in the MANET (e.g. between a server
and a client). This task is equivalent to that of ensuring end-to-
end security in other types of networks, and existing techniques are
therefore applicable.
An orthogonal issue with respect to securing MANET protocols is
ensuring network integrity. So far, MANET protocols in general allow
any node to participate in the network - the assumption being that
all nodes are well-behaving and welcome. If that assumption fails,
i.e. if the network may count malicious nodes, the integrity of the
network may fail. Specific malicious behaviour include, but are not
limited to, jamming (resulting in DoS), incorrect traffic generation
(e.g. server, router or address spoofing), incorrect traffic relaying
(e.g. "man in the middle"), or replay attacks. Most of these threats
are already taken into account in RFC 3756, RFC 3971, and the
security sections of RFC 4861 and RFC 3315.
DoS attacks can highly penalize the operation of IP autoconfiguration
solutions, through increasing the signalling overhead and hence
harming the solutions' convergence time. "Man-in-the-middle" attacks
can cause (i) interception of the IP autoconfiguration messages and
hence operation failure, (ii) messages' modifications leading for
example to changing assigned IP addresses or prefixes during their
transfer and hence causing address or prefix conflicts, (iii)
impersonation, which allows a non-legitimate MANET router to
participate in the IP autoconfiguration process in place of a
legitimate node, and may lead to DoS. On the other hand, IP spoofing
can also lead to impersonation, whereby an IP address can be spoofed
by a non-legitimate node during transfer.
Existing security solutions usually protect network integrity through
authentication guaranteed by a "higher" authority, trusted a priori,
which typically issues the cryptographic keys used to authenticate.
However, for instance in autonomous MANET scenarios, there may not be
any "higher" authority, or if there is, it may not be trusted a
priori by every node in the MANET.
Encryption is thus essential to many existing security mechanisms.
However it may affect convergence time or require a process that is
too heavy in the context of MANETs, since a significant part of the
nodes in a MANET may have limited resources.
Another issue specific to MANETs is related to the potential
selfishness behaviour of some MANET nodes, a.k.a. "the selfish node
problem". This behaviour can cause non-cooperation between MANET
nodes during the IP autoconfiguration process, and hence affect the
operation of autoconfiguration mechanisms.
In the context of MANET IPv6 autoconfiguration, such MANET
characteristics are to be considered in addition to general
characteristics supported by existing IPv6 autoconfiguration
solutions.
8. IANA Considerations
This document does not specify IANA considerations. This document does not specify IANA considerations.
7. References 9. References
7.1. Normative References 9.1. Normative References
[1] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc [1] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc
Network Architecture", ID draft-ietf-autoconf-manetarch, Network Architecture", ID draft-ietf-autoconf-manetarch,
February 2007. February 2007.
7.2. Informative References 9.2. Informative References
[2] Macker, J. and S. Corson, "MANET Routing Protocol Performance [2] Macker, J. and S. Corson, "MANET Routing Protocol Performance
Issues and Evaluation Considerations", RFC 2501, January 1999. Issues and Evaluation Considerations", RFC 2501, January 1999.
[3] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [3] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IPv6", RFC 4861, September 2007. "Neighbor Discovery for IPv6", RFC 4861, September 2007.
[4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6", Carney, "Dynamic Host Configuration Protocol for IPv6",
RFC 3315, July 2003. RFC 3315, July 2003.
skipping to change at page 12, line 12 skipping to change at page 18, line 12
[14] Aura, T., "Cryptographically Generated Addresses (CGA)", [14] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, 2005. RFC 3972, 2005.
[15] Moore, N., "Optimistic Duplicate Address Detection (DAD) for [15] Moore, N., "Optimistic Duplicate Address Detection (DAD) for
IPv6", RFC 4429, 2006. IPv6", RFC 4429, 2006.
[16] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [16] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, 2005. Addresses", RFC 4193, 2005.
[17] Thubert, P. and TJ. Kniveton, "Mobile Network Prefix [17] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6",
Delegation", ID draft-ietf-nemo-prefix-delegation, August 2007.
[18] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6",
RFC 3633, 2003. RFC 3633, 2003.
Contributors Contributors
This document is the result of joint efforts, including those of the Shubhranshu Singh, Samsung.
following contributers, listed in alphabetical order: C. Adjih, C. Email: Shubranshu@gmail.com
Bernardos, T. Boot, T. Clausen, C. Dearlove, U. Herberg, G.
Montenegro, H. Moustafa, C. Perkins, A. Petrescu, P. Ruiz, P. Stupar,
F. Templin, D. Thaler, R. Wakikawa, K. Weniger.
Authors' Addresses Kenichi Mase, Niigata University.
Email: Mase@ie.niigata-u.ac.jp
Emmanuel Baccelli Simone Ruffino, Telecom Italia.
INRIA Email: Simone.Ruffino@telecomitalia.it
Phone: +33 1 69 33 55 11 Carlos J. Bernardos, Universidad Carlos III de Madrid.
Email: cjbc@it.uc3m.es
Hassnaa Moustafa, France Telecom.
Email: Hassnaa.Moustafa@orange-ftgroup.com
Emmanuel Baccelli, INRIA.
Email: Emmanuel.Baccelli@inria.fr Email: Emmanuel.Baccelli@inria.fr
Kenichi Mase Thomas Heide Clausen, LIX, Ecole Polytechnique.
Niigata University Email: T.Clausen@computer.org
Phone: +81 25 262 7446 Acknowledgements
Email: Mase@ie.niigata-u.ac.jp
Simone Ruffino This document benefited from specific feedback, and helpful
Telecom Italia discussions with C. Adjih, T. Boot, C. Dearlove, U. Herberg, G.
Montenegro, C. Perkins, A. Petrescu, P. Ruiz, P. Stupar, F. Templin,
D. Thaler, R. Wakikawa, K. Weniger.
Phone: +39 011 228 7566 Editor's Address
Email: Simone.Ruffino@telecomitalia.it
Shubhranshu Singh Emmanuel Baccelli
Samsung INRIA
Phone: +82 31 280 9569 Phone: +33 1 69 33 55 11
Email: Shubranshu@gmail.com Email: Emmanuel.Baccelli@inria.fr
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 29 change blocks. 
71 lines changed or deleted 316 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/