[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

MANET                                                         S. Ruffino
Internet-Draft                                                 P. Stupar
Expires: April 18, 2005                                            TILAB
                                                              T. Clausen
                                                                     LIX
                                                        October 18, 2004



   Autoconfiguration in a MANET: connectivity scenarios and technical
                                 issues
               draft-ruffino-manet-autoconf-scenarios-00


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.


   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 18, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   MANET interconnection with external networks enables a number of
   usage scenarios, but generates also a number of technical issues,
   mainly related with node autoconfiguration and global connectivity.
   This Internet Draft aims at characterizing global connectivity




Ruffino, et al.          Expires April 18, 2005                 [Page 1]


Internet-Draft              MANET scenarios                 October 2004



   scenarios and listing technical issues related to IP address
   autoconfiguration which are implied by such scenarios and should be
   addressed by a generic solution.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Isolated MANET . . . . . . . . . . . . . . . . . . . . . .  6
     3.2   MANET connected to an external network . . . . . . . . . .  6
       3.2.1   Fixed Gateways . . . . . . . . . . . . . . . . . . . .  8
       3.2.2   Mobile Gateways scenario . . . . . . . . . . . . . . .  9
   4.  Technical issues . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1   Isolated MANET . . . . . . . . . . . . . . . . . . . . . . 11
       4.1.1   General Aspects  . . . . . . . . . . . . . . . . . . . 11
       4.1.2   Stateful Autoconfiguration . . . . . . . . . . . . . . 11
       4.1.3   Stateless Autoconfiguration  . . . . . . . . . . . . . 13
     4.2   Connected MANET  . . . . . . . . . . . . . . . . . . . . . 14
       4.2.1   Prefix Advertisement methods . . . . . . . . . . . . . 14
       4.2.2   Prefixes assignment to the gateways  . . . . . . . . . 15
       4.2.3   Multiple Gateways routing and addressing issues  . . . 15
       4.2.4   Stateful Autoconfiguration . . . . . . . . . . . . . . 17
       4.2.5   Stateless Autoconfiguration  . . . . . . . . . . . . . 17
       4.2.6   NAT Considerations for IPv4  . . . . . . . . . . . . . 17
       4.2.7   Ingress Filtering  . . . . . . . . . . . . . . . . . . 17
       4.2.8   Mobile IP  . . . . . . . . . . . . . . . . . . . . . . 17
       4.2.9   Data Forwarding  . . . . . . . . . . . . . . . . . . . 19
   5.  Architectural considerations . . . . . . . . . . . . . . . . . 20
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
       Intellectual Property and Copyright Statements . . . . . . . . 26

















Ruffino, et al.          Expires April 18, 2005                 [Page 2]


Internet-Draft              MANET scenarios                 October 2004



1.  Introduction


   MANET were initially designed to be employed in highly dynamic and
   unpredicatable environments, characterized by high mobility of users
   and terminals.  MANET are essentially autonomous, self-configuring,
   self-healing networks, whose mobile nodes discover other nodes and
   supported services in an automatic fashion.  MANET routing protocols,
   as studied in IETF, enable two generic MANET nodes to exchange data
   traffic through multi-hop connections, if a 1-hop radio link between
   them is not available.  In this way, nodes can freely move within the
   MANET: routing protocols dynamically react to movement and constantly
   discover and choose the optimal path according to a predifined
   metric, e.g.  number of hops.  If an intermediary node, which belongs
   to a path between a source and a destination, fails traffic is
   automatically re-routed through an alternative path.


   RFC2501 [1] gives a definition of MANET and also introduces the
   possibility to connect a MANET to an external network, by means of
   gateways: in this case the MANET acts as a "stub" network, whose
   nodes route traffic originating and/or terminating within the MANET
   only.


   Operators, Network and Service providers show increasing interest in
   this type of network, as a consequence of the wide spreading of
   low-cost radio technologies such as IEEE802.11a/b/g/h and the
   increasing customer base.  Commercial MANET deployments indicate that
   MANETs are mainly employed as extensions of traditional
   infrastructure networks, to realize the so-called hybrid networks:
   MANET nodes exchange traffic between them using multi-hop paths and
   can reach outside hosts and the Internet by means of the gateways,
   which are equipped with two or more interfaces: a MANET interface and
   typically an interface to one or more non-MANET networks.


   An example of this are the so-called Mesh Networks, used to extend
   the coverage area of a public hot-spot or to realize large-scale
   low-cost wireless coverage in urban areas.  A further interesting
   application and research field is represented by multi-hop cellular
   networks: MANETs connected to cellular WAN networks.  In this case
   MANETs can be used to realize an extended wireless coverage in areas
   where "traditional" cellular network is not available.


   Many proposals and projects that introduce an integration between
   MANET and 3G+ networks exist in this area: among other [2], [3] and
   [4].


   In both isolated and hybrid MANETs, an important technical issue is
   automatic configuration of network parameters on each node: IP
   address, default route, DNS, etc.  At least one unique IP address




Ruffino, et al.          Expires April 18, 2005                 [Page 3]


Internet-Draft              MANET scenarios                 October 2004



   with local scope is needed to enable traffic exchange within a MANET.
   In particular, if a MANET is connected to an external network, IP
   address autoconfiguration rises an additional problem, known as
   "Global Connectivity": the IP address should be globally routable, in
   order for the node to be reachable both from MANET internal nodes and
   external Internet hosts.  The intrinsic high dynamicity of MANETs
   rises additional issues: a MANET could split in two or more
   sub-MANETs, or two or more MANETs could merge in one larger MANET.
   In all these cases, a node could experience problems due to address
   conflicts, reconfiguration and reestablishment of the default route.
   So attention must be paid in such scenarios, expecially when multiple
   gateways are used within the MANET.


   Many solutions addressing autoconfiguration and global connectivity
   issues have been proposed ([5], [8], [11], [6], [7], [9]).  In the
   authors' opinion, there is the need to define a number of MANET
   connectivity scenarios and, consequently, a clear problem statement,
   against which to validate proposed and future solutions.


   This document is structured in the following way: in Section 2 a
   glossary for commonly used terms is given; in Section 3 connectivity
   scenarios for a MANET are listed.  In this section particular
   attention is given to the connection of a MANET with other external
   wireless networks, by means of one or more fixed (Section 3.2.1) or
   mobile wireless gateways (Section 3.2.2).  In Section 4 IPv4 and IPv6
   autoconfiguration and routing issues are derived from the previous
   scenarios, both for an isolated (Section 4.1) and connected (Section
   4.2) MANET.  Some architectural considerations are reported in
   Section 5.























Ruffino, et al.          Expires April 18, 2005                 [Page 4]


Internet-Draft              MANET scenarios                 October 2004



2.  Terminology


   Node
      An IPv4/IPv6 device which is a MANET element: it runs a MANET
      routing protocol and exchanges data with other nodes within a
      MANET and with hosts located within external networks.  A node has
      at least one physical interface connecting it to the MANET.


   Gateway
      A node equipped with at least two interfaces, one of which
      connects it to an external network, i.e.  non-MANET, and can be
      wired or wireless.


   Host
      An IPv4/IPv6 terminal/computer, external to the MANET.  Host is
      defined here as only "External" to differentiate it from the nodes
      of the MANET.


   Wireless Interface (or MANET interface)
      The physical network interface that connects a node to the MANET.


   Radio Interface (or Cellular Interface)
      The physical network interface that may connect a gateway to an
      external Wireless Wide Area Network, owned and administered by an
      operator.


   Stateful autoconfiguration
      A mechanism of address autoconfiguration is defined stateful, when
      a MANET node receives its IP address by another device, acting as
      configuration server, which can be either within or outside the
      MANET.


   Stateless autoconfiguration
      A mechanism of address autoconfiguration is defined stateless when
      a node builds its own address without the partecipation of any
      external device.


   Default route forwarding
      A node transmits all data directed to external networks to one of
      its neighbors, elected as next-hop to the chosen gateway.


   Source route forwarding
      A node transmits all data directed to external networks explicitly
      indicating in each packet's header which gateway must be used to
      forward it.  "Loose Source Routing" for IPv4 has been specified in
      [16]; the "Routing Header" has been specified for IPv6 in [17].






Ruffino, et al.          Expires April 18, 2005                 [Page 5]


Internet-Draft              MANET scenarios                 October 2004



3.  Scenarios


   In this section, we describe the scenarios in which a MANET may
   typically operate and where different address autoconfiguration
   issues arise.


3.1  Isolated MANET


   An isolated MANET is a network that is autonomously set-up between
   wireless mobile nodes localized in the same geographical area.  Nodes
   activate Layer 2 radio links, by which they can exchange traffic with
   their neighbors, and employ an ad-hoc routing protocol, which enables
   multi-hop data forwarding through intermediate nodes.  Routing
   protocol constantly discovers routes between nodes, in a proactive
   ([12], [14]) or reactive fashion ([13], [15]): this enables each node
   to route traffic to all other nodes within the MANET also during
   movements.


   In this type of MANET there is no connection to an external network:
   all traffic is generated by MANET nodes and addressed to MANET nodes.


   Typical applications of this scenario are temporary networks, that
   must be set-up in areas where neither wireless coverage nor
   infrastructure exist.  Examples can be emergency networks used for
   disaster recovery, battlefield applications, electronic surveillance.
   Other examples can be found in occasional work meetings, where
   networks are formed to enable file sharing between co-workers.


3.2  MANET connected to an external network


   In this scenario a MANET is connected to an external network by means
   of one or more gateways (Figure 1).  A generic MANET node, running a
   MANET routing protocol, can exchange data traffic with every other
   node through multi-hop paths and communicate with hosts located in
   the external network, routing its uplink traffic towards a gateway.
   This, in turn, will receive return traffic from the host and will
   route it to the source node.















Ruffino, et al.          Expires April 18, 2005                 [Page 6]


Internet-Draft              MANET scenarios                 October 2004



                                     H1
                                      |
                               +---------------+
                               |   Internet    |**
                               +---------------+  *
                                 *           *     *
                                 *           *      *
                             GW1**           *       GW3
                               |         +--GW2-------+
                               |         |   |
                            ---N1--------+   |
                           /      \          |
                         N4        \        N2
                                    N3-----/




         Figure 1: MANET interconnected to an external network


   Gateways play a critical role here.  If the number of nodes in the
   MANET increases, gateways can become bottlenecks, as they route an
   increasing and possibily huge amount of traffic.  This also depends
   on the available bandwidth on the uplink interface.  Moreover,
   gateways can be equipped with a number of additional features.  For
   example, they could participate to the external routing protocol, in
   order to announce internal routes to external routers and hosts,
   possibly performing some kind of aggregation.  They can act as
   enforcement points for security purposes: they can control access to
   external networks and, following a common practice, they can enforce
   Ingress Filtering on MANET generated traffic.  Finally they can also
   provide services like DNS to MANET nodes.


   This scenario can be expanded, depending on the characteristics of
   the network interface connecting gateways to the external network: it
   can be either wired or wireless, which can, in turn, be of a
   different type with respect to the MANET interface.  In the first
   case Gateways are fixed, while in the second case they can also be
   mobile, as the other MANET nodes.


   Moreover, a MANET can have only one gateway (fixed or mobile) or can
   have multiple gateways (fixed or mobile).  Other than guaranteeing a
   higher degree of reliability and fault tolerance to the entire MANET,
   the presence of multiple gateways permits load balancing among the
   gateways themselves.  This can be very useful especially when the
   external network is a low-throughput cellular WAN, such as GPRS/EDGE,
   in order to not overload a single gateway with traffic potentially
   generated by many nodes at the same time.  Single traffic flows of
   multiple nodes or many flows of a single node can be routed through




Ruffino, et al.          Expires April 18, 2005                 [Page 7]


Internet-Draft              MANET scenarios                 October 2004



   different gateways, consequently suggesting an improvement of the
   overall performances of the MANET.


   Gateways can also be equipped with additional resources in order to
   grant better fault tolerance to the entire MANET: additional energy
   resources, more processing power, more volatile and non-volatile
   memory.  This is especially true in case of fixed gateways, that can
   be directly powered and directly operated.  It is clearly more
   difficult to enhance mobile gateways, due to their limited energy
   resources.


   The following sections detail usage scenarios for fixed and mobile
   gateways.


3.2.1  Fixed Gateways


   In this scenario, gateways are deployed in predefined positions
   planned by the network operator.  Each gateway is connected to the
   external network by means of a wired or wireless interface.


   Mesh networks and networks used for environmental surveillance can be
   categorized under this scenario.


   o  Mesh Networks: these are probably the most widespread ad-hoc
      networks.  In a Mesh Network, user terminals (nodes) exchange
      traffic between them directly through a layer-2 radio link and
      using other nodes or fixed wireless Access Points as intermediate
      relays.  A Mesh Network is typically connected to an external
      infrastructure network by means of fixed wired Access Points,
      which act as gateways and typically connect the Mesh to an
      external infrastructure network.
      Mesh Networks can be further categorized, depending on if the mesh
      is realized only between the wireless Access Points or also
      between all the nodes, which, in this case, run a routing
      protocol.  In fact, in some deployments, intermediate access
      points are equipped with two wireless interfaces: the first
      interface forms the mesh with other peer access points,
      participating in an ad-hoc routing protocol, the second interface
      provides local connectivity to nodes, which cannot set-up a
      network themselves, as they don't run any routing protocol.
      Applications of this networks are Internet public access
      (browsing, email etc.) by mobile users from outdoor areas,
      wireless coverage of corporate building to give employees access
      to shared data and commonly used services (email, Intranet
      browswing).  These solutions can bring to savings on cabling
      costs.






Ruffino, et al.          Expires April 18, 2005                 [Page 8]


Internet-Draft              MANET scenarios                 October 2004



   o  Surveillance networks: several wireless nodes endowed with sensors
      of varios kinds are spread over high enviromental risk areas (e.g.
      fires).  They communicate through multi-hop connections and run a
      routing protocol.  When an emergency situation arises, data
      collected by sensors are transmitted from the collecting nodes
      upwards one or more gateways (which can have both a wired or
      wireless interface) and conveyed to a manned monitoring station.
      Topologies of this kind of network are typically static, as the
      nodes are installed in fixed positions within the monitored areas.
      Moreover, these networks are characterized by multiple constant
      low-throughput data flows going from the sensors to the gateways.


3.2.2  Mobile Gateways scenario


   In this scenario, the gateway's radio interface, connecting the MANET
   to the external network, can be a cellular WAN interface (GSM, GPRS,
   EDGE, UMTS), a broadband wireless MAN (WMAN) interface (e.g.
   802.16x, 802.20) or a WLAN interface (802.11a/b/g/h/j).  In each of
   these cases, gateways can forward uplink traffic outside the MANET
   only if located within the transmission/reception range of one or
   more Base Stations or Access points.  Gateways can therefore not only
   freely move within the coverage area, but they can also move outside
   this area: in such case, the gateway can't forward uplink traffic
   destined for external hosts anymore, nor downlink traffic destined
   for internal nodes.


   The primary benefit of coverage extension is that local communication
   between two nodes of the MANET are preformed without using any
   cellular radio resource, e.g.  radio channels.  Another benefit is
   the possibility to grant network access also to those terminals that
   are not equipped with a cellular radio interface (e.g.  access
   sharing).  The implication of this business model on security and
   accounting aspects are out of the scope of this draft.


   A more advanced scenario can be realized when most of the nodes are
   also equipped with two heterogeneous interfaces.  In this case
   gateways can be "occasional": they can be nodes that, after setting
   up the connection towards the external network, whenever located
   within its coverage area, can start forwarding other nodes' outbound
   packets.  In this kind of scenario, gateways can be "special" nodes
   endowed with additional features, but they can also be ordinary MANET
   nodes, such as mobile phones and PDAs.  In this last case, gateways
   are characterized by low computational power and limited energy
   resources.  Although the MANET can again exploit benefits given by
   multiple gateways, additional issues arise: in fact, gateways are not
   under operators control anymore.  It's possible that the owner of the
   gateway decides abruplty to turn his terminal off or to tear down the
   connection towards the cellular network, in order to save battery




Ruffino, et al.          Expires April 18, 2005                 [Page 9]


Internet-Draft              MANET scenarios                 October 2004



   life.  Thus, the number and the position of gateways are higly
   dynamic and this can cause frequent re-routing of uplink data flows.


   In this situation, autoconfiguration operations performed by nodes
   and gateways assume critical importance, as they have not only to be
   performed by a node on joining the MANET, but also constantly
   repeated, in order to repair broken routes to the gateway.













































Ruffino, et al.          Expires April 18, 2005                [Page 10]


Internet-Draft              MANET scenarios                 October 2004



4.  Technical issues


   The scenarios introduced in the previous sections, raise some
   technical issues that must be addressed both to guarantee the normal
   functionalities of a MANET and to assure an accettable level of
   performance to the applications running on each single node.  Among
   those issues there is particullary the one of the nodes' IPv4/IPv6
   address configuration.


   The purpose of this section is not to propose of a solution to the
   address configuration issue, but to characterize and describe the
   technical aspects, which are related to such issue, affect the
   scenarios descripted above and lack of a standard solution.


4.1  Isolated MANET


   In an isolated MANET scenario, the nodes' addressing issue has been
   already considered by many proposals which furnish a set of
   solutions.  See [21] for a complete and exaustive comparison of such
   proposals.  However, some of these proposals do not cope with all the
   critical aspects that affect the autoconfiguration issue in an
   isolated MANET.


   The purpose of this section is to describe the main critical aspects
   related to the addressing in this scenario.


4.1.1  General Aspects


   As an isolated MANET is characterized by flat addressing: a node must
   only be endowed with an address, unique within the MANET itself.
   There are no limitations on the prefix of such address, both when
   using IPv4 and when using IPv6.


   Therefore, the problem can be reduced to the configuration of an
   unique IP (IPv4 or IPv6) address, without any constraint on the
   chosen prefix.  Such configuration should be made in an efficient and
   automatic way.


   In the following, stateful and stateless approaches are considered
   separately.


4.1.2  Stateful Autoconfiguration


   In an isolated MANET, the role of the configuration server can be
   only assigned within the MANET itself and can be performed by any
   node of the network.  It must be always guaranteed that within a
   MANET there is a node acting as configuration server.  This may not
   be always true, as a MANET can experience a partition during its




Ruffino, et al.          Expires April 18, 2005                [Page 11]


Internet-Draft              MANET scenarios                 October 2004



   existence.  If indeed there is only one node providing stateful
   configuration within a MANET and such a MANET gets partitioned, one
   of the newly-born networks will be without any connection to the
   configuration server.


   Several solutions have been proposed to counter this issue:


   o  Dynamic Election: the role of the configuration server is
      dynamically assigned to one only MANET node.


   o  Server Redundancy: the role of configuration server is distributed
      among more than one terminal of the MANET; it can also be
      distributed among all the MANET nodes.


   When an isolated MANET is endowed with a stateful address mechanism,
   there is the problem of detecting, by means of a Service Discovery
   mechanism, which of the MANET nodes acts as a configuration server.
   This is true both when the configuration service is assigned to a
   single node and when this role is distributed among several nodes.


   Moreover, when the stateful configuration service is not distributed
   among all the nodes, a MANET which has been created by a previous
   partition can be without any configuration server: the problem of the
   configuration server election within such MANET therefore arises.


   Partitioning is not the only event creating some problems with
   respect to addressing.  It can't be excluded that two MANETS merge,
   creating a new MANET, as such kind of networks are characterized by
   the mobility of their elements.  Moreover it can't be excluded that
   two nodes, located in two different MANETs, own the same address (the
   unicity of an address is indeed guaranteed only within the MANET the
   node is connected to).  If these two MANETs merge with each other,
   there would be a newly-born MANET in which two nodes have configured
   the same address.  Such an event surely compromises the normal
   functions of these two nodes, but also of the whole network.  It is
   therefore necessary that a node verifies the unicity of its address
   after a merging.  Such requirement implies the existence of a
   merging-detection mechanism, or that every node keeps on verifying
   the univocity of its address.


   It is worth mentioning that when the stateful configuration is
   executed by means of more than one server, it is possible that within
   a MANET, two of such servers assign the same address to two nodes:
   the problem of the DAD execution therefore arises, otherwise it is
   necessary that a coordination mechanism exists among servers, which
   assures that assigned addresses belong to disjoint addressing space.






Ruffino, et al.          Expires April 18, 2005                [Page 12]


Internet-Draft              MANET scenarios                 October 2004



4.1.3  Stateless Autoconfiguration


   If the configuration mechanism is stateless, there are several
   issues, depending on the used Internet protocol.  A stateless
   configuration mechanism has been standardized both for IPv4 and for
   IPv6.  Such mechanisms are based upon the assumption that all the
   nodes of the network are located on the same link: this assumption is
   not valid for MANETs.  Moreover, such solutions don't guarantee that
   the configured address is unique, and therefore a DAD mechanism is
   still needed.  We assume here that a global prefix is not available
   in the MANET.


   o  In case of IPv4, the standard stateless configuration mechanism is
      ZEROCONF [19]: through its use, a node configures itself a
      link-local address derived from the prefix 169.254.0.0/16.


   o  In the case of IPv6 the standard stateless configuration is
      defined IPv6 stateless autoconfiguration [18] and assures the
      automatic configuration of a link-local address on network
      interfaces by using the well known prefix fe80::/16.  The suffix
      of such address is the EUI-64 identifier, which is derived from
      IEEE 802 identifier of network interfaces through which the nodes
      are connected to the network.  The uniqueness of such addresses is
      not guaranteed if the network is made of nodes having
      heterogeneous interfaces, in particular when one or more of them
      are connected to the network by means of interfaces that have no
      IEEE 802 identifier (e.g.  Bluetooth).  Such nodes must be endowed
      with a mechanism that lets them generate a suffix which will be
      used to set up the link-local address through stateless
      configuration.  It is, however, not guaranteed that the generated
      address is unique and that a DAD mechanism is therefore still
      required.  The issues related to the use of link-local addresses
      within a MANET, listed in [5] , can be summarized by asserting
      that IPv6 prevents the nodes from communicating with such type of
      addresses along multi-hop paths.


   o  In ZEROCONF, the DAD mechanism is based upon ARP messages
      exchange, which is used by the nodes to defend their address and
      to detect the presence of a duplicate address.  In IPv6 the same
      mechanism is based upon exchange of Neighbor Solicitation and
      Neighbor Advertisement messages.  In both cases (IPv4 and IPv6),
      the DAD mechanism has been defined to be executed within LANs,
      which are networks whose elements are on the same link.  As cited
      before, in a MANET, such an assumption is not valid: it is
      therefore necessary to introduce a standard DAD mechanism which is
      able to detect that two nodes use the same address even when such
      nodes are not directly connected on the same link.





Ruffino, et al.          Expires April 18, 2005                [Page 13]


Internet-Draft              MANET scenarios                 October 2004



   o  It can't be excluded that two nodes located into two different
      MANETS own the same address also when the configuration mechanism
      is stateless and not only in the case of a stateful approach: if
      these two MANET merge, there will be two nodes having the same
      address in the new MANET.  It is therefore necessary that MANET
      nodes verify the uniqueness of their address not only when they
      enter the MANET, but also after a merging.  Such requirement
      implies the necessity of a merging-detection mechanism or the
      necessity of a continuos DAD execution, as stated in section
      Section 4.1.2.  For example, [19] and [18] define the continuos
      defense of nodes' addresses.
      Incidentally, partitioning do not imply any issue, as addresses
      are trivially unique before and after the MANET gets partitioned.


4.2  Connected MANET


   If the MANET is connected to an external IP network, e.g.  the
   Internet, the address configuration must let the MANET nodes to
   communicate with hosts located in the external network.  In turn,
   this implies the configuration of an IPv4 or IPv6 global address: the
   network interface partecipating to the MANET routing protocol must be
   configured with at least one globally routable address, which can be
   public or private (only for IPv4).  In case of public addressing,
   such an address must be derived from a prefix which must be globally
   valid, while in the case of private IPv4 addressing there must be a
   NAT agent somewhere.  We assume here that prefixes are managed and
   announced by gateways in the MANET.


   Several issues related to global IP address configuration can be
   characterized.  Some of these are similar to those described in
   section Section 4.1, however, there are some scenarios that create
   further aspects that must be considered.  The most complex scenarios
   are particularly the ones characterized by the presence of multiple
   gateways and multiple prefixes.  In such situations a MANET indeed
   experiences high dynamicity, as described in section Section 3.2.


4.2.1  Prefix Advertisement methods


   It is firstly necessary considering the ways through which prefixes
   are announced within a MANET.  Two general approaches exist: prefix
   information is inserted into routing protocol messages or inserted
   into other protocol messages.  In the first case it is necessary an
   opportune extension of routing protocol: the solutions could not be
   general enough, as the global connectivity is tied to every single
   routing protocol.  Using a routing protocol can optimize the
   diffusion, the choice and the management of the prefixes that must be
   used: a deeper description of such aspect is given in Section 4.2.3.
   Viceversa, if prefix advertisement is independent from the routing




Ruffino, et al.          Expires April 18, 2005                [Page 14]


Internet-Draft              MANET scenarios                 October 2004



   protocol, it is necessary the definition of new mechanisms or the
   modifications to existing ones.  IPv6 Neighbor Discovery, for
   example, must be adapted to the multi-hop nature of the MANET paths.


4.2.2  Prefixes assignment to the gateways


   For this purpose, gateways must own the prefixes which they announce
   within the MANET.  It is possible to assume that they are manually
   configured on gateways, but this approach is problematic if it is
   applied to dynamic scenarios such as those described in Section
   3.2.2.  In this scenario, gateways can appear or disappear within a
   MANET in an unpredictable way.  Gateways should therefore
   automatically receive the global prefixes associated to the MANET
   they are connected to, e.g.  through a prefix delegation mechanism
   [23], that, moreover, lets external routers install automatically the
   proper routes towards the MANET.


4.2.3  Multiple Gateways routing and addressing issues


   The presence of multiple active gateways can improve the overall
   robustness of the MANET, as described in Section 3.2.  In fact,
   gateway redudancy guarantees a higher fault tolerance: for example,
   if a gateway fails, nodes, which are using such gateway, can
   dynamically change their own default gateway and continue to
   communicate with external hosts.


   Multiple gateways can improve global MANET performance if nodes are
   enabled to concurrently route traffic through more than one gateway.
   If all the MANET nodes used the same gateway as default gateway,
   leaving the others as pure back-up, load balancing among different
   gateways would not be exploited.


   Moreover, if uplink traffic is supposed to be sent towards different
   gateways and if also downlink traffic is supposed to be received from
   different gateways, the choice of the prefix used by a node to
   configure its address assumes critical importance.  In fact, IP
   source address used for uplink traffic determines the gateway to
   which the return traffic will be sent.  It is desiderable that
   traffic follows the same path uplink and downlink within the MANET:
   this is because the uplink path towards the default gateway is
   guaranteed to be optimal by routing the protocol.


   However, in case of multiple gateways / multiple prefixes in the
   MANET, the following can arise (as depicted in Figure 2): a node N1
   elects a default gateway GW1, receives prefixes form it, configures
   its global address, begins a data session with an external host H1.
   Both uplink and downlink traffic are delivered through GW1.  Then the
   node moves away from its position and find itself near another




Ruffino, et al.          Expires April 18, 2005                [Page 15]


Internet-Draft              MANET scenarios                 October 2004



   gateway, GW2, which has a better routing metric than the previous
   gateway, which is now many hops away (namely, N4 - N3 - N2).  The
   node elects this as default gateway, but keeps its old global
   address, in order not to disrupt the session.  Downlink traffic
   follows in this case a non-optimal path within the MANET, which can
   be potentially very long: the bandwidth available to the user (and to
   other MANET nodes) may descrease dramatically.  It is therefore
   desiderable that the return traffic flows towards the default gateway
   of the source node.



                           ---------->H1
                          /           |
                         /     +---------------+
                        /    +-|   Internet    |---+
                       /     | +---------------+   |
                       |     |                     |
                       |  GW1++                  +GW2
                       |   |   \                /
                       v   |    \N2----N3----N4/
                          N1



                           -----------H1<------------
                          /           |              \
                         /     +---------------+      \
                        /    +-|   Internet    |---+   \
                       /     | +---------------+   |    |
                       |     |                     |    |
                       |  GW1++                  +GW2+  |
                       \-----\ \                /    |  |
                              \ \N2----N3----N4+     |  |
                               \--------------\ \----N1
                                               ------^



            Figure 2: Multiple gateways non-optimal routing


   In this scenario, a critical situation arises when one or more
   gateways are no longer reachable from MANET nodes (e.g.  because
   MANET gets partitioned or gateways fail or simply shut-off).  In this
   case, nodes, whose global addresses are associated to such gateways ,
   are no more globally reachable and should configure a new address.
   Mobile IP can handle this address change.  See Section 4.2.8 for
   considerations on this approach.







Ruffino, et al.          Expires April 18, 2005                [Page 16]


Internet-Draft              MANET scenarios                 October 2004



4.2.4  Stateful Autoconfiguration


   Differently from what happens in an isolated MANET, in hybrid MANETs
   the configuration server can also be located in the external network.
   This option requires more attention and a deeper analysis,
   particulary in the scenarios of Section 3.2.2, where gateways can
   activate and deactivate abruptly.  The major issue here comes from
   the fact that a node may not reach the external server, thus
   experimenting high delays and session disruption.


4.2.5  Stateless Autoconfiguration


   If the connected MANET uses a stateless autoconfiguration mechanism,
   same considerations as in Section 4.1.3 arise.  In this case, the
   node must be able to configure a global address: this must be derived
   from a globally valid prefix, which is also used to install routes
   towards the MANET within the external network.  Issues related to
   discovery of such prefixes and DAD have been described in Section
   4.2.1 and Section 4.1.3, respectively.


4.2.6  NAT Considerations for IPv4


   If any NAT mechanism is deployed, the problem of the prefix
   diffusion, which is described in Section 4.2.1 and Section 4.2.2, is
   avoided as the node in the MANET can choose a random address and use
   it to partecipate to the routing protocol.  However, the nodes of a
   MANET whose gateways use NAT mechanism to achieve global
   connectivity, as described in [24], experience a session break if
   they change the gateway used to send uplink traffic.


4.2.7  Ingress Filtering


   Ingress filtering is a security mechanism often implemented on sites
   border routers, which could also be deployed on gateways of a
   connected MANET.  It consists in blocking all the outbound packets
   whose source address does not belong to a prefix advertised within
   the MANET.  This means that in a MANET with multiple gateways, which
   advertise multiple prefixes, nodes that have received a prefix from a
   gateway must also use the same gateway to route uplink traffic.  In
   such a MANET, a node which changes its default gateway, must also
   change its address, in order to be able to continue to transmit
   traffic towards external networks.


4.2.8  Mobile IP


   This section highligths some issues raised by the use of Mobile IP in
   MANETs.





Ruffino, et al.          Expires April 18, 2005                [Page 17]


Internet-Draft              MANET scenarios                 October 2004



   In many of the scenarios described above, particularly in those of
   Section 3.2, a MANET node may have to change its IP address.  Reasons
   for this can be the following:


   o  a node moves to a separate MANET, where different global prefixes
      are advertised;


   o  the gateway, that is advertising the prefix used to configure a
      node's address, fails: in this case downlink traffic directed to
      such prefix cannot be delivered to the MANET anymore;


   o  ingress filtering (see Section 4.2.7 ) is deployed in the MANET to
      improve security;


   o  as seen in Section 4.2.3 a node could change its address in order
      to use always an optimal path both for uplink and downlink
      traffic, thus acheiving better performances.


   In order to handle this address changes, Mobile IP ([20]) can be
   deployed on MANET nodes.  Mobile IP is commonly used to avoid data
   session disruption after a mobile node changes its IP address as a
   consequence of a change of point of attachment to the Internet.  A
   MANET with multiple gateways can be considered as an overlapping set
   of different access networks, if gateways advertise multiple global
   prefixes.


   The use of standard Mobile IP (either for IPv4 or IPv6) in this
   scenario can imply several issues, described in the following.


   o  In the scenario described in Section 4.2.3, where multiple egress
      gateways can concurrently be active, a node could change its
      address frequently.  This brings to the "Binding Storm" problem:
      if many nodes in the MANET change their addresses at the same
      time, a very high number of Binding Update messages (or
      Registration Request, if Mobile IPv4 is used) will be generated,
      therby overloading the MANET and gateways in particular.


   o  If Mobile IPv4 is used, some nodes with special functions, such as
      Foreign Agent or DHCP server, must be located within the MANET in
      order to assign a valid address to the nodes.  If the Foreign
      Agent approach is used, two more mechanisms are needed: a
      discovery mechanism for Foreign Agents and a mechanism which
      enables multi-hop transmission of Advertisement and Registration
      Request/Response messages within the MANET.  If the DHCP approach
      is used, same consideration hold as those described in Section
      4.2.4.  Moreover, if robustness is needed and one employs
      redundant agents, synchronization issues may arise.





Ruffino, et al.          Expires April 18, 2005                [Page 18]


Internet-Draft              MANET scenarios                 October 2004



   o  If Mobile IPv6 is used, the major issue is related to Movement
      Detection.  In fact, Movement Detection is realized by means of
      Router Advertisements: if these messages are not present in the
      MANET, i.e.  prefixes are advertised through MANET routing
      messages, standard Mobile IPv6 procedure will not work.  Moreover,
      Router Advertisements were not designed to be multi-hop, so same
      considerations as in Section 4.1.3 and Section 4.2.1 apply.


4.2.9  Data Forwarding


   There can be two methods which a node can use to forward data traffic
   towards external networks : default route and source routing.  Both
   methods, applied in the reference scenarios described above, have
   pros and cons.


   If the default route method is employed, intermediate nodes of a path
   from a source node to a gateway may not have elected the same default
   gateway as the source node.  This means that data can flow towards a
   different egress gateway: if ingress filtering is deployed,
   communication is not possible.  If source routing is used, data can
   flow through a gateway explicitly chosen by source node.


   Moreover, if a default route is used, load balancing in the MANET
   could be problematic as, again, nodes can't control the path data
   follow through the gateway.



























Ruffino, et al.          Expires April 18, 2005                [Page 19]


Internet-Draft              MANET scenarios                 October 2004



5.  Architectural considerations


   There are many different proposal that solve many of the issues
   described above.  As already mentioned, the objective of this draft
   is not to give a survey of state of the art solutions, nor to address
   problems that such solutions pose.  It is, however, needed to clarify
   what architectural choices are more effective, in order to design a
   comprehensive solution for both autoconfiguration and global
   connectivity problems.  Two important aspects are the following.



   o  Layering : this means integration between different protocols
      (autoconfiguration, mobility, routing).  It can bring the
      definition of optimized mechanims, exploiting information passed
      from one protocol to another (e.g.  to perform movement
      detection).  From a different point of view, it is however
      desiderable to keep different functionalities separated from each
      other, in order to get a modular approach.


   o  Nodes with specific functionalities: in some scenarios one can
      deploy some special nodes, enabled with mechanisms such as DHCP,
      NAT, Foreign Agent, gateway, that have, for example, a fixed
      connection to external network and are equipped with more
      energetic resources than "normal" nodes.  In this case these
      special nodes perform all "operational" tasks and normal nodes are
      only source or destination for data traffic and are only requested
      to run a MANET routing protocol.  In this case, if a special node
      fails, unpredictable results are possible, that can bring to the
      failure of the entire MANET.  Moreover, in a very large MANET
      (i.e.  big cardinality), it can be difficult to mantain an
      acceptable level of performance with only one active gateway,
      which can become a bottleneck for outbound traffic.




















Ruffino, et al.          Expires April 18, 2005                [Page 20]


Internet-Draft              MANET scenarios                 October 2004



6.  Security Considerations


   This document raises no security issue.

















































Ruffino, et al.          Expires April 18, 2005                [Page 21]


Internet-Draft              MANET scenarios                 October 2004



7.  IANA Considerations


   This document has no actions for IANA.


8  References


   [1]   Corson, S. and J. Macker, "Mobile ad hoc networking (MANET):
         Routing protocol performance issues and evaluation
         considerations", RFC 2501, January 1999.


   [2]   Siebert, M., "On Ad Hoc Networks in the 4G Integration
         Process", Med-Hoc 2004 , June 2004.


   [3]   "Ambient Networks", http://www.ambient-networks.org .


   [4]   "World Wireless Research Forum",
         http://www.wireless-world-research.org .


   [5]   Wakikawa, R., Malinen, J., Perkins, C., Nilsson, A. and A.
         Tuominen, "Global connectivity for IPv6 Mobile Ad Hoc
         Networks", I-D draft-wakikawa-manet-globalv6-03.txt, October
         2003.


   [6]   Cha, H., Park, J. and H. Kim, "Extended Support for Global
         Connectivity for IPv6 Mobile Ad Hoc Networks", October 2003.


   [7]   Jeong, J., Park, J., Kim, H. and D. Kim, "Ad Hoc IP Address
         Autoconfiguration", I-D
         draft-jeong-adhoc-ip-addr-autoconf-02.txt, February 2004.


   [8]   Perkins, C., Malinen, J., Wakikawa, R. and E. Belding-Royer,
         "IP Address Autoconfiguration for Ad Hoc Networks", I-D
         draft-perkins-manet-autoconf-01.txt, November 2001.


   [9]   Singh, S., Kim, JH., Choi, YG., Kang, KL. and YS. Roh, "Mobile
         multi-gateway support for IPv6 mobile ad hoc networks", I-D
         draft-singh-manet-mmg-00.txt, June 2004.


   [10]  Paakkonen, P., Rantonen, M. and J. Latvakoski, "IPv6 addressing
         in a heterogeneous MANET-network", I-D
         draft-paakkonen-addressing-htr-manet-00.txt, December 2003.


   [11]  Jelger, C., Noel, T. and A. Frey, "Gateway and address
         autoconfiguration for IPv6 adhoc networks", I-D
         draft-jelger-manet-gateway-autoconf-v6-02.txt, April 2004.


   [12]  Clausen, T. and P. Jacquet, "Optimized link state routing
         protocol", RFC 3626, October 2003.




Ruffino, et al.          Expires April 18, 2005                [Page 22]


Internet-Draft              MANET scenarios                 October 2004



   [13]  Perkins, C., Belding-Royer, E. and S. Das, "Ad hoc On-Demand
         Distance Vector (AODV) Routing", RFC 3561, July 2003.


   [14]  Ogier, R., Templin, F. and M. Lewis, "Topology Dissemination
         Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February
         2004.


   [15]  Johnson, D., Maltz, D. and Y. Hu, "The Dynamic Source Routing
         Protocol for Mobile Ad Hoc Networks (DSR)", I-D
         draft-ietf-manet-dsr-10.txt, July 2004.


   [16]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
         1981.


   [17]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.


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


   [19]  Aboba, B., "Dynamic Configuration of Link-Local IPv4
         Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in
         progress), July 2004.


   [20]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.


   [21]  Sun, Y. and E. Belding-Royer, "A study of dynamic addressing
         techniques in mobile ad hod networks", I-D Wireless
         communication and mobile computing, May 2004.


   [22]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", RFC 2461, December 1998.


   [23]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
         Configuration Protocol (DHCP) version 6", RFC 3633, December
         2003.


   [24]  Engelstad, P., T—nnesen, A., Hafslund, A. and G. Egeland,
         "Internet Connectivity for Multi-Homed Proactive Ad Hoc
         Networks", First IEEE International Conference on Sensor and Ad
         hoc Communications and Networks , October 2004.










Ruffino, et al.          Expires April 18, 2005                [Page 23]


Internet-Draft              MANET scenarios                 October 2004



Authors' Addresses


   Simone Ruffino
   Telecom Italia LAB
   Via G.Reiss Romoli 274
   Torino  10148
   Italy


   Phone: +39 011 228 7566
   EMail: simone.ruffino@telecomitalia.it



   Patrick Stupar
   Telecom Italia LAB
   Via G.Reiss Romoli 274
   Torino  10148
   Italy


   Phone: +39 011 228 5727
   EMail: patrick.stupar@telecomitalia.it



   Thomas Heide Clausen
   Laboratoire d'informatique
   Ecole Polytechnique
   Palaiseau Cedex  91128
   France


   Phone: +33 1 6933 2867
   EMail: thomas.clausen@polytechnique.fr






















Ruffino, et al.          Expires April 18, 2005                [Page 24]


Internet-Draft              MANET scenarios                 October 2004



Appendix A.  Acknowledgments


   The authors would like to thank Ivano Guardini for his valuable
   comments.
















































Ruffino, et al.          Expires April 18, 2005                [Page 25]


Internet-Draft              MANET scenarios                 October 2004



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 (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.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Ruffino, et al.          Expires April 18, 2005                [Page 26]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/