Subject: [Autoconf] Problem Statement: input and discussions on the list

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 26 Jul 2006 14:44:07 +0200

Hi all,

I would like to stir up the discussion about the Problem Statement 
draft, as we want to move on to a 01 version soon. I encourage everyone 
to read the I-D in detail (you will find it in attachement) and to bring 
to the attention of the list any potential input or issue one may think 
of. As a starting point, here is a list of items that we are looking to 
address for 01 (if you have additional items in mind, please do speak up):

-- ITEM 1:
in Section 2
Should we list all possible scenarios and then specify a selection of 
targeted scenarios? Or list only targeted scenarios and suppress the 
Scenario Selection section?

-- ITEM 2:
in Section 2
Do we need to be more precise about "External Networks"? This 
denomination is for now used in the document to mean things as diverse 
as the Internet, or simply another MANET that does not merge with the 
first one etc. Do we need to be more precise?

-- ITEM 3:
overall the document
Should we replace the "MANET-DAD" denomination with simple "DAD"  
denomination?

-- ITEM 4:
in Section 5
Is the phases diagram clear enough? Generic enough?

Cheers
Emmanuel

MANET Autoconfiguration (Autoconf)                     E. Baccelli (Ed.)
Internet-Draft                                                     INRIA
Expires: January 25, 2007                                        K. Mase
                                                      Niigata University
                                                              S. Ruffino
                                                          Telecom Italia
                                                                S. Singh
                                                                 Samsung
                                                           July 24, 2006

 Address Autoconfiguration for MANET: Terminology and Problem Statement
                  draft-baccelli-autoconf-statement-00

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 January 25, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Traditional dynamic IP address assignment solutions are not adapted
   to mobile ad hoc networks.  This document elaborates on this problem,
   states the need for a new solution, and provides guidelines and

Baccelli (Ed.), et al.  Expires January 25, 2007                [Page 1]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

   requirements for its design.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Overview of the Problem  . . . . . . . . . . . . . . . . .  3
     1.2.  Specification of Requirements  . . . . . . . . . . . . . .  3
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Standalone MANET . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  MANET Connected to an External Network . . . . . . . . . .  5
   3.  Deployment Scenarios Selection . . . . . . . . . . . . . . . .  6
   4.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Specific Broacast Characteristics  . . . . . . . . . . . .  7
     4.2.  Dynamic Topology . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Locally Unique Addresses, Globally Unique Addresses  . . .  8
     4.4.  Multiple Gateways  . . . . . . . . . . . . . . . . . . . .  8
   5.  Solution Guidelines  . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Solution Model . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  General Requirements . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Contributors   . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

Baccelli (Ed.), et al.  Expires January 25, 2007                [Page 2]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

1.  Introduction

   Mobile ad hoc networks (i.e.  MANETs, refer to RFC 2501) are networks
   composed of mobile devices also called nodes, that communicate over
   wireless media, and which dynamically self-organize multi-hop
   communication between each other.  Each node may generate and
   forwards control traffic, and forward user traffic (thus potentially
   behaving like a router).  Each node may also use the network by
   generating user traffic (and thus potentially behaving like a host).

   Some mobile ad hoc network may function regardless of the
   availability of a connection to the infrastructure (i.e. the
   Internet).  More precisely, a MANET may either be disconnected from
   the fixed IP infrastructure (then called a standalone MANET), or
   connected to the fixed IP infrastructure (through one or more
   gateways).

1.1.  Overview of the Problem

   Prior to participation in IP communication, each node's interface on
   a MANET that does not beneficiate from appropriate static
   configuration needs to be automatically assigned at least one IP
   address, that SHOULD be unique (i) locally, for communication inside
   the MANET, or (ii) globally, for communication accross the Internet.
   However, standard automatic IP address assignment solutions do not
   work "as-is" on MANETs due to ad hoc networks' characteristics, and
   new mechanisms are therefore needed.  The goal of this document is to
   detail these problems, and to provide guidelines and requirements for
   solutions to be designed.

1.2.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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 [RFC2119].

1.3.  Terminology

   In addition to the specific wording described in the previous
   section, this document uses the following terminology :

   MANET Node  - A device with one or more wireless interfaces and
      associated IP address(es) which is used by the MANET routing
      protocol in use.

Baccelli (Ed.), et al.  Expires January 25, 2007                [Page 3]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

   Local address  - An IP address configured on a MANET node and valid
      for communication among MANET nodes that are part of the same ad
      hoc network.  Nodes MUST NOT communicate with other nodes outside
      the MANET using this address.

   Global address  - An IP address configured on a MANET node and valid
      for communication with nodes in the Internet, as well as
      internally within the MANET.

   Internet gateway  - An edge node connected to MANET as well as to the
      Internet and capable of providing bidirectional connectivity
      between the Internet and MANET .  These gateways are expected to
      provide topologically correct IPv6 prefixes.  Internet gateways
      mostly run ad hoc routing protocols, but they can also run
      infrastructure network protocols (e.g.  OSPF).

   Duplicate Address Detection (DAD)  - The process by which a node
      confirms the uniqueness of an address it wishes to configure or
      has already configured.  A node already equipped with an IP
      address participates in DAD in order to protect its IP address
      from being used by another node.

   Pre-service MANET-DAD  - The process verifying that a tentative new
      IP address assignment will not create a conflict with other MANET
      devices.

   In-service MANET-DAD  - The process of continuously checking that an
      IP address already in use has not become duplicated in the MANET.

   Standalone MANET  - An independent ad hoc network which has no
      connectivity, either direct of via Internet gateways, to any other
      IP networks such as the Internet.

   Network merger  - The process by which two or more ad hoc networks,
      previously disjoint, get connected.  In general, network merger
      happens as a consequence of node mobility and/or wireless link
      environment.

   Network partitioning  - The process by which an ad hoc network splits
      into two or more disconnected ad hoc networks.  In general, this
      proccess happens as a consequence of node mobility and/or wireless
      link environment.

Baccelli (Ed.), et al.  Expires January 25, 2007                [Page 4]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

2.  Deployment Scenarios

   Automatic configuration of IP addresses of MANET nodes (AUTOCONF) may
   be necessary in a number of deployment scenarios.  In this section,
   we outline the use cases that concern and reveal problems related to
   the Autoconfiguration of MANET nodes.

2.1.  Standalone MANET

   In this kind of scenario, the MANET is not connected to any external
   network: all traffic is generated by MANET nodes and destined to
   nodes in the same MANET.  Nodes joining a standalone MANET can either
   (i) have no previous configuration, or (ii) already have one or more
   MANET local and/or global addresses, statically or dynamically pre-
   configured, to be used for IP communication.  Due to partitions and
   mergers, standalone MANETs can often be composed with both kinds of
   nodes.

   Typical applications of this scenario include private or temporary
   networks, set-up in areas where neither wireless coverage nor network
   infrastructure exist (e.g. emergency networks for disaster recovery,
   or conference-room networks).

2.2.  MANET Connected to an External Network

   In this scenario, the MANET is connected to an external network,
   (e.g. the Internet), by means of one or more gateways.  MANET nodes
   can generate traffic directed to remote hosts accross the Internet.
   As in Section 2.1, nodes in a connected MANET could either (i)
   already own a global IP address, which could be used for external
   traffic, or (ii) have no previous configuration.

   Examples include public wireless networks of scattered fixed WLAN
   Access Points participating in the MANET of mobile users, and acting
   as Internet Gateways.  Another example of such a scenario is the
   coverage extension of a fixed wide-area wireless network, where one
   or more mobile nodes in the MANET are connected to the Internet
   through technologies such as UMTS or WiMAX.

Baccelli (Ed.), et al.  Expires January 25, 2007                [Page 5]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

3.  Deployment Scenarios Selection

   TBD

Baccelli (Ed.), et al.  Expires January 25, 2007                [Page 6]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

4.  Problem Statement

   MANET nodes that do not beneficiate from appropriate static IP
   address configuration may need to automatically configure at least
   one unique local IPv6 address, in order to enable IP communication
   within the MANET.

   To communicate with hosts across the Internet, configuration
   mechanism may also need to provide one or more global IPv6 addresses.
   Internet Gateways typically manage topologically correct IPv6
   prefixes that can be used to configure global address.  They are
   usually managed by an administrative entity (i.e. a network operator
   or service provider), however they can also be opportunistic and
   unmanaged.  Internet Gateways are typically fixed, but may also be
   mobile.  Their presence in the MANET may be intermittent (the number
   of gateways may vary), and thus the availability of an Internet
   connection in the MANET may also be intermittent.

4.1.  Specific Broacast Characteristics

   Traditional dynamic IP address assignment solutions, such as RFC
   2462, 3315 and 2461, do not work as-is in MANETs due to these
   networks' unique properties, as elaborated in the following sections.
   These solutions assume that a broadcast direclty reaches every device
   on the network, whereas it is generally not the case in MANETs.
   Indeed, some nodes in the MANET will typically be indirectly
   connected to the source of the broadcast, through several
   intermediate peer mobile ad hoc nodes.  In that respect, it is worth
   noting that IPv6 does not currently specify an address scope that is
   applicable for MANET scope.

4.2.  Dynamic Topology

   A significant proportion of the nodes in the MANET may be mobile with
   wireless interface(s), leading to ever changing neighbors and
   neighbor sets for most MANET nodes.  Therefore network topology may
   change rather dynamically compared to traditional networks.  In
   particular, phenomena such as MANET paritionning (i.e. a MANET
   separating into two or more disconnected MANETs) and MANET merging
   (i.e. two or more disconnected MANETs suddenly being connected) are
   potential events that may greatly disrupt the uniqueness of IP
   addresses in use.  For instance, a standalone MANET A may feature
   nodes that use IP addresses that are locally unique within MANET A,
   but this uniqueness is not guaranteed anymore if MANET A merges at
   some point with another MANET B.

Baccelli (Ed.), et al.  Expires January 25, 2007                [Page 7]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

4.3.  Locally Unique Addresses, Globally Unique Addresses

   Moreover, even if a node uses an IP address that is locally unique
   within its MANET, this address may not be fit for Internet
   communication.  Indeed, in order to be able to communicate with
   outside the MANET (i.e. the Internet), a node must use an IP address
   that must be both globally unique, as well as topologically correct,
   reflecting it's current location.

4.4.  Multiple Gateways

   In the case where multiple gateways are available in the MANET,
   specific problems arise.  One problem is the way in which global
   prefixes are managed within the MANET.  If *one* prefix is used for
   the whole MANET, partitioning of the MANET may invalid routes in the
   Internet towards MANET nodes.  On the other hand, use of *multiple*
   network prefixes guarantees traffic is unambiguously routed towards
   the gateway owning one particular prefix, but asymmetry in the nodes'
   choice of ingress/egress gateway can lead to non-optimal paths
   followed by inbound/outbound data traffic.  Additional problems come
   from issues with current IPv6 specifications.  For example, the
   strict application of RFC2462 may lead to check every IPv6 unicast
   for uniqueness : in a multiple-gateway / multiple-prefixes MANET,
   this could bring to a large amount of control signalling, due to
   frequent reconfiguration.

Baccelli (Ed.), et al.  Expires January 25, 2007                [Page 8]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

5.  Solution Guidelines

5.1.  Solution Model

   This section proposes a high-level conceptual view of generic MANET
   autoconfiguration.  The different phases of the autoconfiguration
   process are abstracted by means of a diagram (see Fig. 1), that may
   serve as conceptual framework of the issues that nodes have to solve.
   However, note that solutions do not have to follow this framework.
   The purpose of this framework is merely to derive a checklist of
   autoconfiguration functionalities, in order to build solutions
   taylored for different scenarios.

   Basically, with regards to IP addressing, a device may find itself
   into the 3 different phases depicted in Fig 1. :

   The NO ADDRESS phase -  In this phase a device does not have its own
      IP address.  It does not participate in user data forwarding.  If
      a routing protocol is in use in the MANET, the node does not
      process, generate or forward routing control messages generated by
      other devices.  At some point, the node may generate a (tentative)
      address by means of a given address generation method.  When it
      generates its address, the device should enter the ADVERTISING
      phase.

   The ADVERTISING phase -  In this phase, a device does not participate
      in user data forwarding.  If a routing protocol in in use in the
      MANET, the node does not forward routing control messages
      generated by other nodes.  In this phase, the node may perform
      pre-service MANET-DAD by means of a given mechanism (for instance
      by using specific control signalling, that could be embeded in the
      ad hoc routing signalling in use).  If pre-service MANET-DAD is
      used, and the device detects that its tentative address creates a
      conflict with other MANET devices, it should re-enters the NO
      ADDRESS phase.  Else, if pre-service MANET-DAD completes without
      any address conflict being detected, or if pre-service DAD is not
      required, the node should enter the NORMAL phase.  Note that if
      pre-service MANET-DAD is used, the ADVERTISING phase may have
      incremental substates in order to reduce the risks of routing
      table pollution with duplicate addresses.  In the LOCAL
      ADVERTISEMENT phase, pre-service MANET-DAD control signalling
      reaches only a TTL-limited neighborhood, whereas in the GLOBAL
      ADVERTISEMENT phase, pre-service MANET-DAD control signalling
      reaches the whole MANET.

Baccelli (Ed.), et al.  Expires January 25, 2007                [Page 9]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

   The NORMAL phase -  In this phase, the device participates in IP
      communication normally.  If a routing protocol is in use in the
      MANET, the device may process, generate or forward routing control
      messages as specified by the routing protocol in use, and may
      generate or forward user data.  A device in this phase may perform
      in-service MANET-DAD by means of a given mechanism (for instance
      by using specific control messages that can be embeded in the
      routing control messages).  If in-service MANET-DAD is used and if
      the device detects an address conflict that forces it to acquire a
      new address to resolve this conflict, the node should return to
      the NO ADDRESS phase.  Note that the phases in this model are
      cyclic, and that a node can pop up in the MANET in any phase.  For
      instance, a node that beneficiated from appropriate static
      preconfiguration may start directly in the NORMAL phase.

                  (Address generation)              (In-service MANET-DAD)

                   +--------------+ Duplicate address  +--------------+
                   |  NO ADDRESS  |     detected       |    NORMAL    |
        +----------|    phase     |<-------------------|    phase     |<--+
        |          +--------------+                    +--------------+   |
        |                      ^                                          |
        |                      | Duplicate address                        |
        |(Tentative) address   |     detected                     Address |
        |   generated          +--------+                         checked |
        |                               |                                 |
        |    +--------------------------------------------------------+   |
        |    |                 ADVERTISING phase                      |   |
        |    |                                                        |   |
        |    |     +--------------+                  +-------------+  |   |
        |    |     |  LOCAL AD.   |                  | GLOBAL AD.  |  |   |
        +--->|     |    phase     |----------------->|   phase     |  |---+
             |     +--------------+                  +-------------+  |
             +--------------------------------------------------------+

                              (Pre-service MANET-DAD)

                 Fig. 1 Generic autoconfiguration phases.

   This conceptual framework reveals three specific potential aspects of
   the problem, which solutions MUST be designed take into account:

      - The (tentative) IP addresses generation and assignment aspect.

      - The pre-service DAD aspect, to somehow ensure a reasonalble
      belief in the fact that an address about to be assigned does not

Baccelli (Ed.), et al.  Expires January 25, 2007               [Page 10]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

      create a conflict.

      - The in-service DAD aspect, to deal with conflicts that are
      detected between already assigned addresses.

5.2.  General Requirements

   A solution for IP address autoconfiguration for MANETs is needed for
   mobile ad hoc node to acquire a correct IP address prior to their
   full participation in the mobile ad hoc routing protocol(s) in use.
   Such a solution must address the distributed, multi-hop nature of
   mobile ad hoc networks.  Autoconfiguration mechanisms must be able to
   follow changes in the MANET and react to gateway connectivity loss,
   or to the event of new gateways becoming available, (re)configuring
   addresses accordingly.  A solution must achieve its task with minimal
   overhead, due to scarse bandwidth, and minimal delay, due to the
   dynamicity of the topology.

Baccelli (Ed.), et al.  Expires January 25, 2007               [Page 11]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

6.  Security Considerations

   Address configuration in MANET could be prone to security attacks, as
   in other type of IPv6 networks.  Security threats to IPv6 neighbor
   discovery are discussed in RFC 3756: in particular, analysis includes
   trust model and threats for a specific ad hoc network scenario, where
   all the nodes share a common link (i.e. they are one hop away from
   each other, full-meshed connectivity is available).  Although the
   document does not explicitly address MANETs, where nodes can be
   multiple hop away from each other, the trust model it provides could
   be valid also in the context of AUTOCONF.  It is also worth noting
   that, in case of MANET connected to the Internet, other threats
   defined in RFC3756 could apply here, e.g. attacks involving routers
   and DoS attacks on Duplicate Address Detection procedures.

   Analysis has to be further extended to include threats, specific to
   multi-hop networks and, in particular, related to the address
   configuration process: security issues of routing protocol operations
   (e.g. how to secure routing protocol messages) are out of scope of
   AUTOCONF WG.

Baccelli (Ed.), et al.  Expires January 25, 2007               [Page 12]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

7.  IANA Considerations

   This document does currently not specify IANA considerations.

8.  References

   [1]  Macker, J. and S. Corson, "MANET Routing Protocol Performance
        Issues and Evaluation Considerations", RFC 2501, January 1999.

   [2]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
        for IPv6", RFC 2461, December 1998.

   [3]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
        Carney, "Dynamic Host Configuration Protocol for IPv6",
        RFC 3315, July 2003.

   [4]  Narten, T. and S. Thomson, "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.

Baccelli (Ed.), et al.  Expires January 25, 2007               [Page 13]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

Contributors

   This document is the result of joint efforts, including those of the
   following contributers, listed in alphabetical order: C. Adjih
   (INRIA), T. Clausen (Ecole Polytechnique), C. Perkins (Nokia), P.
   Ruiz (University of Murcia), P. Stupar (Telecom Italia), D. Thaler
   (Microsoft).

Baccelli (Ed.), et al.  Expires January 25, 2007               [Page 14]

Internet-Draft      MANET Autoconf Problem Statement           July 2006

Authors' Addresses

   Emmanuel Baccelli
   INRIA

   Phone: +33 1 69 33 55 11
   Email: [email-masked]

   Kenichi Mase
   Niigata University

   Phone: +81 25 262 7446
   Email: [email-masked]

   Simone Ruffino
   Telecom Italia

   Phone: +39 011 228 7566
   Email: [email-masked]

   Shubhranshu Singh
   Samsung

   Phone: +82 31 280 9569
   Email: [email-masked]

Baccelli (Ed.), et al.  Expires January 25, 2007               [Page 15]

Internet-Draft      MANET Autoconf Problem Statement           July 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
   [email-masked].

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.

Baccelli (Ed.), et al.  Expires January 25, 2007               [Page 16]

_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: "Yi, Seung" <[email-masked]>
Date: Wed, 26 Jul 2006 14:12:54 -0700

Hi, all,

I got a question and a comment.

First, the question. What would be the utility of the TTL-limited
MANET-DAD described in Section 5.1, Advertising phase. I understand the
utility of MANET-wide DAD but I don't see the point of having a
TTL-limited DAD support. What am I missing?

Now the comments. I don't think LOCAL AD phase and GLOBAL AD phase
should be disjoint as pictured in the diagram in Section 5. Why
shouldn't a MANET node configure a MANET-local address and also a
globally routable address to a MANET interface at the same time?

For ITEM2, the document reads to me as it primarily considers some kind
of hierarchical network structure where a MANET attaches to a
higher-tier network as in the case where a MANET attaches to the
Internet as a stub. Related to that, are there any proposals to
designate the boundary or membership of a particular MANET? For example,
when a MANET splits into two, do they become different MANETs or stay as
the same MANET but partitioned? And when they merge back to one, how
would one know the two used to belong in the same MANET? Will this have
to be enforced by address assignment or by some external mechanism? I'm
just wondering if anyone has some insights to share. 

Regards,

- Seung

-----Original Message-----
From: Emmanuel Baccelli [mailto:[email-masked]] 
Sent: Wednesday, July 26, 2006 5:44 AM
To: [email-masked]
Subject: [Autoconf] Problem Statement: input and discussions on the list

Hi all,

address for 01 (if you have additional items in mind, please do speak
up):

-- ITEM 1:
in Section 2

-- ITEM 2:
in Section 2

-- ITEM 3:
overall the document

-- ITEM 4:
in Section 5

Cheers
Emmanuel

---

From: mase <[email-masked]>
Date: Thu, 27 Jul 2006 10:40:18 +0900

Dear Seung,

Thank you for your comments. Please see comments in line.

>TTL-limited DAD support. What am I missing?

Routing protocol may use TTL-limited routing control messages, such as 
Hello messages in proactive routing protocols and TTL-limited RREQ in 
reactive routing protocols. A tentative address can be advertised using 
these control messages, leading to TTL-limited DAD.

>globally routable address to a MANET interface at the same time?

Global AD means a tentative address advertised MANET-wide, leading to 
possible MANET-wide DAD. It is not related to whether address is 
MANET-local or global.

Regard,
Kenichi

---

From: Seung Yi <[email-masked]>
Date: Wed, 26 Jul 2006 18:49:21 -0700

Dear Kenichi,

Thank you for your reply. I can see that there is a possibility to piggyback
DAD messages to RREQ. But Would that be useful? One would be able to
discover that a tentative address is not being used within the given TTL by
doing so but I'm not sure what that buys him.

I guess I understood it wrong. Could you provide some more details on the
Local AD case? When would that be used and for what purpose? I can see
Global AD is basically when a node does the MANET-wide DAD. I'm not quite
sure if I understood the Local AD phase.

Thanks,

- Seung

---

From: mase <[email-masked]>
Date: Thu, 27 Jul 2006 13:04:46 +0900

Dear Seung,

>sure if I understood the Local AD phase.

I understand your question. If perfect DAD for a tentative address is 
required, a node may skip Local AD and directly proceed to Global  AD. If 
applications need only limited number of hops communication, only Local AD 
may be sufficient and Global AD may be skipped. Anyway, Figure 1 is a 
reference model, where all possible phases are included. It doesn't mean 
all phases and sub-phases are useful for a given application and scenario.

Cheers,
Kenichi