Subject: RE: [Autoconf] Review of draft-ietf-autoconf-statement-01

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Nov 2007 11:06:12 +0100

All,

More comments on the Problem Statement.

First of all, I would like that the document is lined up with the charter. I
think the primary goal is "Develop an IPv6 address autoconfiguration
mechanism" and NOT work on prefix delegation. I think those are very
different. And I think existing prefix delegation mechanisms can be used. So
why invent something that can be reused? The charter is very clear on this.

Then I want descriptions of problems with MLA and MGA (L=local, G=global). I
think problems for the two types are very different, as MGAs must be
globally routable and topologically correct and generation has to do with
Border Routers. Note that an MGA can be used as MLA, MLA cannot be used as
MGA. I think MLA are to be used as failback when no MGA can be generated,
e.g. just after startup MN and in a Standalone MANET.

Then I want the focus on IPv6 unique address generation. I want a list of
all current methods, and the probability / risks on duplicates. My personal
opinion is that some methods can provide almost absolutely uniqueness, other
methods cannot. Here is also a link to a security issue, e.g. address
spoofing. My personal opinion is that duplicates caused by spoofing is a far
more important problem than collisions. And a remedy for the spoofing
security issue would solve collisions also. Or it shall be described why
not.

Recently, the relation with routing is discussed. I think there are
problems. Number one is the routing protocol convergence. It takes time for
the MANET protocol to adopt a newly generated address, and during
convergence connectivity from other nodes and border routers in the MANET to
the node with the newly generated address is bad.
The second relation is for MGA and the relation between Border Routers used
for MGA generation. This problem is described in the current text. Maybe
text should specify more precisely what the problem really is. 
Current text:
>>> When a device changes its MANET border router attachment ...
How can a device changes its MANET border router attachment? OK, it can
generate a new MGA for using that border router. But it cannot attach to
that border router, this is up to the routing protocol and is dependent on
other nodes. This is a large problem, with as a result traffic blocking by
ingress filters on border routers not accepting MGAs as source with prefixes
not belonging to that border outer.
Following text on asymmetry may be removed, it has to do with routing and
not with addressing.
>>> asymmetry in the routers' choice of ingress/egress MANET border
>>> router can lead to non-optimal paths followed by inbound/outbound
>>> data traffic

Text on Deployment Scenarios should be taken out and inserted in the MANET
Architecture document.

On references:
There are new RFCs for IPv6 ND and Autoconf (RF4861, RFC4862).
Following references should be added:
RFC4291: IP Version 6 Addressing Architecture
RFC3041: Privacy Extensions for Stateless Address Autoconfiguration in IPv6
RFC3971: SEcure Neighbor Discovery (SEND)
RFC3972: Cryptographically Generated Addresses (CGA)
RFC4429: Optimistic Duplicate Address Detection (DAD) for IPv6
RFC4193: Unique Local IPv6 Unicast Addresses
Also consider:
draft-ietf-nemo-prefix-delegation: Mobile Network Prefix Delegation
Consider removing references to:
RFC2328: OSPF version 2
RFC2740: OSPF for IPv6 
draft-ietf-manet-iana: Allocations for the  Mobile Ad hoc Networks (MANET)
Working Group

Changing references implies changing text. Maybe adding lots of text.

Thanks,
Teco.

_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Nov 2007 11:53:09 +0100

Teco Boot wrote:
> First of all, I would like that the document is lined up with the 
> charter. I think the primary goal is "Develop an IPv6 address 
> autoconfiguration mechanism" and NOT work on prefix delegation. I 
> think those are very different. And I think existing prefix 
> delegation mechanisms can be used. So why invent something that can 
> be reused? The charter is very clear on this.

Err... I'm agreeing with you to have a PS aligned with the Charter.  But
  I don't understand: do you disagree reusing DHCP PD? ("NOT work on
prefix delegation").  I may misunderstand you.

> Then I want descriptions of problems with MLA and MGA (L=local, 
> G=global). I think problems for the two types are very different, as 
> MGAs must be globally routable and topologically correct and 
> generation has to do with Border Routers.

Sorry what's MG/LA other than global/local?  M?  A?

It's strange to talk about topologically correct addresses when the
strong assumption in MANETs is that the topology changes.  In a sense
any address is correct in a topology changing to follow it.

Or maybe one AUTOCONF requirement is to support dynamic L2 topology
changes with a overlay stable L3 topologies?  Or vice-versa?  Or none?

I think the problem (and solution) is very different if we consider the
L3 topology be stable over a fixed L2 topology vs L3-variable/L2-variable.

For example, if we consider a MANET to be a set of PDAs physically
moving around wifi range, but keeping their L2 and L3 topologies stable,
then the obvious solution is DHCPv6-PD there's no need of anything else.
  And if this is a typical deploying scenario then we're all happy.

If on the other hand we consider a MANET to be a pda+laptop+phone
personal set dynamically changing the way it intra-connects and
Internet-connects then we can have a whole different set of solutions.
But is this a relevant scenario, pertinent from market perspective -
question mark.

Unfortunately to me, the current scenarios in the PS draft aren't
detailed enough, and too theoretical.  For example they only briefly
mention "emergency network", "UMTS", "WiMAX" at the end of sections.
And there are so many ways and types deployed of emergency networks and
umts and wimax where there's no problem of address auto-configuration -
because they use ppp/dhcp/L2IPaddressassignment.

I think I have a big problem understanding AUTOCONF overall.  I don't
understand the requirements.

> Note that an MGA can be used as MLA, MLA cannot be used as MGA. I 
> think MLA are to be used as failback when no MGA can be generated, 
> Then I want the focus on IPv6 unique address generation. I want a 
> list of all current methods, and the probability / risks on 
> duplicates. My personal opinion is that some methods can provide 
> almost absolutely uniqueness, other methods cannot. Here is also a 
> link to a security issue, e.g. address spoofing. My personal opinion 
> is that duplicates caused by spoofing is a far more important problem
> than collisions. And a remedy for the spoofing security issue would
> solve collisions also. Or it shall be described why not.
> 
> problems.

I agree.

> Number one is the routing protocol convergence.

Then number zero is to make simply routing (strike protocol), make the
default route meaningful and work overall in the presence of topology
changes (L2?  L3?).

> It takes time for the MANET protocol to adopt a newly generated 
> address, and during convergence connectivity from other nodes and 
> border routers in the MANET to the node with the newly generated 
> address is bad. The second relation is for MGA and the relation 
> between Border Routers used for MGA generation. This problem is 
> described in the current text. Maybe text should specify more 
> precisely what the problem really is. Current text:
> How can a device changes its MANET border router attachment? OK, it 
> can generate a new MGA for using that border router. But it cannot 
> attach to that border router, this is up to the routing protocol and 
> is dependent on other nodes. This is a large problem, with as a 
> result traffic blocking by ingress filters on border routers not 
> accepting MGAs as source with prefixes not belonging to that border 
> outer. Following text on asymmetry may be removed, it has to do with 
> routing and not with addressing.
>>>>  router can lead to non-optimal paths followed by 
>>>> inbound/outbound data traffic
> 
> Text on Deployment Scenarios should be taken out and inserted in the 
> MANET Architecture document.

Somehow yes... in my reading (IMHO) the current text on Deployment
Scenarios could largely benefit from augmenting with, err, deployment
scenarios.  More talk of vehicles, handsetphones, walkietalkies, pdas,
gameconsoles, temperaturesensors, antennapoles, videocameras, gpsunits,
audiorecorders - all IP yes.

ALso, a list of requirements in the form of:

Req 0 - should do this.
Req 1 - should do that.

could help a lot understanding, methinks.

> On references: There are new RFCs for IPv6 ND and Autoconf (RF4861, 
> RFC4862). Following references should be added: RFC4291: IP Version 6
>  Addressing Architecture RFC3041: Privacy Extensions for Stateless 
> Address Autoconfiguration in IPv6 RFC3971: SEcure Neighbor Discovery 
> (SEND) RFC3972: Cryptographically Generated Addresses (CGA) RFC4429: 
> Optimistic Duplicate Address Detection (DAD) for IPv6 RFC4193: Unique
> Local IPv6 Unicast Addresses Also consider: 
> Consider removing references to: RFC2328: OSPF version 2 RFC2740: 
> OSPF for IPv6 draft-ietf-manet-iana: Allocations for the  Mobile Ad 
> hoc Networks (MANET) Working Group

I agree.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 16 Nov 2007 12:19:08 +0100

Hi all, authors, Thomas, Teco,

Thanks for the feedback. Here's an updated version of the PS taking into 
account recent comments by Thomas and Teco. Aside from fixing various 
editorial details that they pointed out, the main upgrades concern:

* the introduction in the terminology section of the term ICP, standing 
for Internet Configuration Provider, lifting an ambiguity about border 
routers' potential funtionalities in MANETs.

* the tightening of the definition/use of "prefix" and "address" related 
terms.

* more precision in relating to existing protocols' scope as well as the 
one of the protocols-yet-to-be-designed.

* updated references

I encourage everyone to continue the public reviewing and discussions on 
this updated basis, until it is published (the plan is to submit soon ;)

Cheers,

Emmanuel

> Changing references implies changing text. Maybe adding lots of text.

MANET Autoconfiguration (Autoconf)                     E. Baccelli (Ed.)
Internet-Draft                                                     INRIA
Expires: May 19, 2008                                            K. Mase
                                                      Niigata University
                                                              S. Ruffino
                                                          Telecom Italia
                                                                S. Singh
                                                                 Samsung
                                                       November 16, 2007

 Address Autoconfiguration for MANET: Terminology and Problem Statement
                    draft-ietf-autoconf-statement-02

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 May 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Baccelli (Ed.), et al.    Expires May 19, 2008                  [Page 1]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

Abstract

   Traditional dynamic IPv6 address assignment solutions are not adapted
   to mobile ad hoc networks.  This document elaborates on this problem,
   states the need for new solutions, and requirements to these
   solutions.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Connected MANET  . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Standalone MANET . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Deployment Scenarios Selection . . . . . . . . . . . . . .  6
   4.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  MANET Autoconfiguration Goals  . . . . . . . . . . . . . .  7
       4.1.1.  Multi-hop Support  . . . . . . . . . . . . . . . . . .  7
       4.1.2.  Dynamic Topology Support . . . . . . . . . . . . . . .  8
       4.1.3.  Network Merging Support  . . . . . . . . . . . . . . .  8
       4.1.4.  Network Partitioning Support . . . . . . . . . . . . .  9
     4.2.  MANET Autoconfiguration Issues . . . . . . . . . . . . . .  9
       4.2.1.  Address and Prefix Generation  . . . . . . . . . . . .  9
       4.2.2.  Prefix and Address Uniqueness Requirements . . . . . . 10
       4.2.3.  Internet Configuration Provider Related Issues . . . . 10
   5.  Solutions Considerations . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 15
   Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

Baccelli (Ed.), et al.    Expires May 19, 2008                  [Page 2]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

1.  Introduction

   A Mobile Ad hoc NETwork (also known as a MANET [1]) consists of a
   loosely connected set of MANET routers.  Each MANET router embodies
   IP routing/forwarding functionality and may also incorporate host
   functionality [2].  These routers dynamically self-organize and
   maintain a routing structure among themselves, regardless of the
   availability of a connection to any infrastructure.

   MANET routers may be mobile and may communicate over symmetric or
   assymetric wireless links.  They may thus join and leave the MANET at
   any time, at a rate that can be substantially higher than in usual
   networks.

   However, prior to participation in IP communication, each MANET
   router that does not benefit from appropriate static configuration
   needs to automatically acquire at least one IP address, and may also
   need to be delegated an IP prefix.  This address or this prefix may
   be required to be unique within a given scope, or to be topologically
   appropriate.

   Standard automatic IPv6 address assignment and prefix delegation
   solutions [5], [3] [4] do not work "as-is" on MANETs due to ad hoc
   networks' unique characteristics [2].  Therefore new or modified
   mechanisms are needed for operation within MANET scope, and this
   document thus details and categorizes the issues that need to be
   addressed.

Baccelli (Ed.), et al.    Expires May 19, 2008                  [Page 3]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

2.  Terminology

   This document uses the terminology defined in [2], as well as the
   following terms :

   MANET Local Prefix (MLP)  - An IP prefix delegated to a MANET router,
      consisting in chunks of IP addresses valid for communications
      inside the MANET.

   MANET Local Address (MLA)  - An IP address configured on a MANET
      interface, and valid for communications inside the MANET.

   Global prefix  - An IP prefix delegated to a MANET router, consisting
      in chunks of IP addresses valid for communications reaching
      outside the MANET (as well as communications within the MANET).

   Global address  - An IP address configured on an interface and valid
      for communications reaching outside the MANET (as well as
      communications within the MANET).

   Internet Configuration Provider (ICP)  - A router that can provide
      other routers requesting configuration with addresses or prefixes
      derived from a global prefix.

   Connected MANET  - A mobile ad hoc network, which contains at least
      one ICP.

   Standalone MANET  - A mobile ad hoc network, which does not contain
      any ICP.

   Network merger  - The process by which two or more previously
      disjoint ad hoc networks get connected.

   Network partitioning  - The process by which an ad hoc network splits
      into two or more disconnected ad hoc networks.

   Address generation  - The process of selecting a tentative address
      with the purpose of configuring an interface.

   Address assignment  - The process of configuring an interface with a
      given address.

   Pre-service address uniqueness  - The property of an address which is
      assigned at most once within a given scope, and which is unique,
      before it is being used.

Baccelli (Ed.), et al.    Expires May 19, 2008                  [Page 4]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

   In-service address uniqueness  - The property of an address which was
      assigned at most once within a given scope, and which remains
      unique over time, after the address has started being used.

Baccelli (Ed.), et al.    Expires May 19, 2008                  [Page 5]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

3.  Deployment Scenarios

   Automatic configuration of IP addresses on MANET interfaces and
   prefix delegation to MANET routers are necessary in a number of
   deployment scenarios.  This section outlines the different categories
   of scenarios that are considered.

3.1.  Connected MANET

   Connected MANETs are mobile ad hoc networks which contain at least
   one ICP, i.e. a router that can provide other routers requesting
   configuration with addresses or prefixes derived from a global
   prefix.  Routers joining a connected MANET may either (i) have no
   previous configuration, or (ii) already own pre-configured local or
   global IP addresses (or prefixes).

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

3.2.  Standalone MANET

   Standalone MANETs are mobile ad hoc networks which do not contain any
   ICP, i.e. which do not contain any router able to provide other
   routers requesting configuration with addresses or prefixes derived
   from a global prefix.  Again, routers joining a standalone MANET may
   either have (i) no previous configuration, or (ii) pre-configured
   local or global IP addresses (or prefixes).  Due to potential network
   partitions and mergers, standalone MANETs may be composed of routers
   of either types.

   Typical instances 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).

3.3.  Deployment Scenarios Selection

   Both "Standalone MANET" and "Connected MANET" scenarios are to be
   addressed by solutions for MANET autoconfiguration.  Note that
   solutions should also aim at addressing cases where a MANET transits
   from one scenario to an other.

Baccelli (Ed.), et al.    Expires May 19, 2008                  [Page 6]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

4.  Problem Statement

   This section details the goals of MANET autoconfiguration.  A
   taxonomy of autoconfiguration issues specific to MANETs is then
   elaborated.

4.1.  MANET Autoconfiguration Goals

   A MANET router needs to configure IP addresses and prefixes as usual,
   on its non-MANET interfaces as well as its attached hosts and
   routers, if any.  In addition, a MANET router needs to configure a
   link local address, or an MLA on its MANET interface and it may also
   require a delegated MLP, provided prefix uniqueness is guaranteed
   [2].

   The primary goal of MANET autoconfiguration is thus to provide
   mechanisms for IPv6 prefix delegation and address assignment for
   operation on mobile ad hoc networks.  Note that this task is distinct
   from that of propagating knowledge about address or prefix location,
   as a routing protocol does (see for example [8], [9]), or as
   described in [7].

   The mechanisms employed by solutions to be designed must address the
   distributed, multi-hop nature of MANETs [2], and be able to follow
   topology and connectivity changes by (re)configuring addresses and/or
   prefixes accordingly.

   Traditional dynamic IP address assignment protocols, such as [5], [3]
   or [4], do not work efficiently (if at all) on MANETs, due to these
   networks' unique properties.  The following thus overviews what must
   be specifically supported for efficient operation on mobile ad hoc
   networks.

4.1.1.  Multi-hop Support

   Traditional solutions assume that a broadcast directly reaches every
   router or host on the subnetwork, whereas this generally is not the
   case in MANETs (see [2]).  Some routers in the MANET will typically
   assume multihop broadcast, and expect to receive through several
   intermediate relayings by peer MANET routers.  For example, in Fig.
   1, the MANET router MR3 cannot communicate directly with a DHCP
   server [4] that would be available through a MANET border router,
   since the server and the MANET router are not located on the same
   logical link.  While some DHCP extensions (such as the relay-agent
   [11]) overcome this issue in a static network, it is not the case in
   a dynamic topology, as explained below.

Baccelli (Ed.), et al.    Expires May 19, 2008                  [Page 7]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

                                                       ----- MR1...MR3
                                                      /      .
              +-------------+         +------------+ /       .
              |             |   p2p   |  MANET     |/        .
              |  ISP Edge   |   Link  |  Border    |         .
              |   Router    +---------+  Router    |\        .
              |             |         |            | \       .
              +-------------+         +------------+  \----- MR2

                       Fig. 1. Connected MANET router topology.

4.1.2.  Dynamic Topology Support

   A significant proportion of the routers in the MANET may be mobile
   with wireless interface(s), leading to ever changing neighbor sets
   for most MANET routers (see [1]).  Therefore, network topology may
   change rather dynamically compared to traditional networks, which
   invalidates traditional delegation solutions that were developed for
   infrastructure-based networks, such as [11], which do not assume
   intermittent reachability of configuration server(s), and a
   potentially ever changing hierarchy among devices.  For instance, in
   Fig. 1, even if MR1 would be able to delegate prefixes to MR3 with
   DHCP [4], it cannot be assumed that MR1 and MR3 will not move and
   become unable to communicate directly.  Moreover, possible frequent
   reconfiguration due to intermittent reachability cause [5] to be less
   efficient than expected, due to large amounts of control signalling.

4.1.3.  Network Merging Support

   Network merging is a potential event that was not considered in the
   design of traditional solutions, and that may greatly disrupt the
   autoconfiguration mechanisms in use (see [2]).  Examples of network
   merging related issues include cases where a MANET A may feature
   routers and hosts that use IP addresses that are locally unique
   within MANET A, but this uniqueness is not guaranteed anymore if
   MANET A merges with another MANET B. If address uniqueness is
   required within the MANET (see Section 4.2.2), issues arise that were
   not accounted for in traditional networks and solutions.  For
   instance, [5] and [3] test address uniqueness via messages that are
   sent to neighbors only, and as such cannot detect the presence of
   duplicate addresses configured within the network but located several
   hops away.  However, since MANETs are generally multi-hop, detection
   of duplicate addresses over several hops is a feature that may be
   required for MANET interface address assignment (see Section 4.2.2).

Baccelli (Ed.), et al.    Expires May 19, 2008                  [Page 8]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

4.1.4.  Network Partitioning Support

   Network partitioning is a potential event that was not considered in
   the design of traditional solutions, and that may invalidate usual
   autoconfiguration mechanisms (see [2]).  Examples of related issues
   include cases such as a standalone MANET, whereby connection to the
   infrastructure is not available, possibly due to network partitioning
   and loss of connectivity to a MANET border router.  The MANET must
   thus function without traditional address allocation server
   availability.  While stateless protocols such as [5] and [3] could
   provide IP address configuration (for MANET interfaces, loopback
   interfaces), these solutions do not provide any mechanism for
   allocating "unique prefix(es)" to routers in order to enable the
   configuration of host interfaces.

                          ----- MR1...MR3...MR5
                         /      .
                        /       .
                       /        .
                    MR4         .
                       \        .
                        \       .
                         \----- MR2

                       Fig. 2. Standalone MANET router topology.

4.2.  MANET Autoconfiguration Issues

   Taking into account the shortcomings of traditional solutions in the
   mobile ad hoc context, this section categorizes general issues with
   regards to MANET autoconfiguration.

4.2.1.  Address and Prefix Generation

   The distributed nature of MANETs brings the need for address
   generation algorithms that can complement existing solutions by
   supporting operation outside "client-server" schemes and without
   fixed hierarchies to provide routers with appropriate addresses and
   prefixes.  In addition, the multi-hop aspect of MANETs brings
   specific needs as far as address and prefix uniqueness is concerned,
   as detailed below.

Baccelli (Ed.), et al.    Expires May 19, 2008                  [Page 9]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

4.2.2.  Prefix and Address Uniqueness Requirements

   If prefix or address uniqueness is required within a specific scope,
   and if the address/prefix generation mechanism in use does not ensure
   address/prefix uniqueness, then additional issues arise.  This
   section overviews these problems.

   Pre-service Issues -- Address or prefix uniqueness problems in this
   category are called pre-service issues.  Conceptually, they relate to
   the fact that before a generated address or prefix is assigned and
   used, it should be verified that it will not create an address
   conflict within the specified scope.  This is essential in the
   context of routing, where it is desireable to reduce the risks of
   loops due to routing table pollution with duplicate addresses.

   In-Service Issues -- Address or prefix uniqueness problems in this
   category are called in-service issues.  They come from the fact that
   even if an assigned address or prefix is currently unique within the
   specified scope, it cannot be ensured that it will indeed remain
   unique over time.

   Phenomena such as MANET merging and MANET partitioning may bring the
   need for checking the uniqueness (within the specified scope) of
   addresses or prefixes that are already assigned and used.  This need
   may depend on (i) the probability of address conflicts, (ii) the
   amount of the overhead for checking uniqueness of addresses, and
   (iii) address/prefix uniqueness requirements from applications.

   For instance, if (i) is extremely low and (ii) significant, then
   checking pre-service uniqueness of addresses and prefixes may not be
   used.  If on the other hand (i) is not extremely low, then checking
   pre-service and in-service uniqueness of addresses or prefixes may be
   required.  In any case, if the application has a hard requirement for
   address uniqueness assurance, in-service uniqueness checks of
   addresses and prefixes should always be used, no matter how unlikely
   is the event of address conflict.

4.2.3.  Internet Configuration Provider Related Issues

   Another category of problems concern the management of Internet
   configuration providers (ICPs).

   In the case where multiple ICPs are available in the MANET, providing
   access to multiple address configuration servers, 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 result in invalid routes towards MANET
   routers, over the Internet.  On the other hand, the use of multiple

Baccelli (Ed.), et al.    Expires May 19, 2008                 [Page 10]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

   network prefixes guarantees traffic is unambiguously routed from the
   hosts/routers in the Internet towards the border router responsible
   for one particular prefix.  However, asymmetry in the routers' choice
   of ingress/egress border router can lead to non-optimal paths
   followed by inbound/outbound data traffic, or to broken connectivity,
   if egress filtering is being done.

   When a device changes its ICP attachment, some routes may be broken,
   affecting MANET packet forwarding performance and applications.  In a
   multiple border router / multiple-prefixes MANET, frequent
   reconfiguration could cause a large amount of control signalling (for
   instance if [5] is used).

Baccelli (Ed.), et al.    Expires May 19, 2008                 [Page 11]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

5.  Solutions Considerations

   Solutions must achieve their task with (i) low overhead, due to
   scarse bandwidth, and (ii) low delay/convergence time, due to the
   dynamicity of the topology.  The evaluation of such criteria may
   depend on the targeted network properties, which include (but are not
   limited to) node cardinality, node mobility characteristics, etc.

   Solutions are to be designed to work at the network layer and thus to
   apply to all link types.  However, in situations where link-layer
   multicast is needed it is possible that on some link types (e.g.
   NBMA links), alternative mechanisms or protocols specifying operation
   over a particular link type would be required.

   Solutions must interact with existing protocols in a way that
   leverages as much as possible appropriate mechanisms that are
   deployed.  For instance, besides the possible use of the well-known
   IPv6 multicast addresses defined for neighbor discovery in [3] (e.g.
   for Duplicate Address Detection), solutions may as well use some
   addresses defined in [10] for auto-configuration purposes.  However,
   it must be ensured that no modification of existing protocols is to
   be required outside of MANET scope.

   Solutions must also take into account the security and trust issues
   that are specific to ad hoc networking (see Section 6).

Baccelli (Ed.), et al.    Expires May 19, 2008                 [Page 12]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

6.  Security Considerations

   Address configuration in MANET could be prone to security attacks, as
   in other types of IPv6 networks.  Security threats to IPv6 neighbor
   discovery were discussed in SEND WG and described in [6]: three
   different trust models are specified, with varying levels of trust
   among network nodes and routers.  Among them, the model by which no
   trust exists among nodes may be suitable a priori for most ad hoc
   networks.  However, the other two models may be applicable in some
   cases, for example when a trust relationship exists between an
   operator and some MANET routers, or between military devices that are
   in the same unit.  Although [6] does not explicitly address MANETs,
   the trust models it provides for ad hoc networks can be valid also in
   the context of MANET autoconfiguration.

   It is worth noting that analysis of [6] is strictly related to
   Neighbor Discovery, Neighbor Unreachability Detection and Duplicate
   Address Detection procedures, as defined in [3] and [5].  As
   explained in the present document, current standard procedures cannot
   be used as-is in MANET context to achieve autoconfiguration of MANET
   routers and, therefore, design of new mechanisms can be foreseen.

   In this case, although security threats and attacks defined in [6]
   could also apply in presence of new solutions, additional threats and
   attacks could be possible (e.g., non-cooperation in message
   forwarding in multi-hop communications).  Therefore, the security
   analysis has to be further extended to include threats, specific to
   multi-hop networks and related to the particular address
   configuration solution.

   General security issues of ad hoc routing protocols' operations are
   not in the scope of MANET autoconfiguration.

Baccelli (Ed.), et al.    Expires May 19, 2008                 [Page 13]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

7.  IANA Considerations

   This document does currently not specify IANA considerations.

Baccelli (Ed.), et al.    Expires May 19, 2008                 [Page 14]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

8.  Informative References

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

   [2]   Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc
         Network Architecture", ID draft-ietf-autoconf-manetarch,
         February 2007.

   [3]   Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
         "Neighbor Discovery for IPv6", RFC 4861, September 2007.

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

   [5]   Narten, T., Thomson, S., and T. Jinmei, "IPv6 Stateless Address
         Autoconfiguration", RFC 4862, September 2007.

   [6]   Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
         Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.

   [7]   Draves, R. and D. Thaler, "Default Router Preferences and More-
         Specific Routes", RFC 4191, 2005.

   [8]   Moy, J., "OSPF version 2", RFC 2328, 1998.

   [9]   Moy, J., Coltun, R., and D. Ferguson, "OSPF for IPv6",
         RFC 2740, 1999.

   [10]  Chakeres, I., "Internet Assigned Numbers Authority (IANA)
         Allocations for the  Mobile Ad hoc Networks (MANET) Working
         Group", ID draft-ietf-manet-iana, May 2007.

   [11]  Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
         2001.

Baccelli (Ed.), et al.    Expires May 19, 2008                 [Page 15]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

Contributors

   This document is the result of joint efforts, including those of the
   following contributers, listed in alphabetical order: C. Adjih, C.
   Bernardos, T. Boot, T. Clausen, C. Dearlove, H. Moustafa, C. Perkins,
   A. Petrescu, P. Ruiz, P. Stupar, F. Templin, D. Thaler, K. Weniger.

Baccelli (Ed.), et al.    Expires May 19, 2008                 [Page 16]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

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 May 19, 2008                 [Page 17]

Internet-Draft      MANET Autoconf Problem Statement       November 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.

Intellectual Property

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

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Baccelli (Ed.), et al.    Expires May 19, 2008                 [Page 18]

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 16 Nov 2007 12:41:41 +0100

Hi Teco, see inline

> why invent something that can be reused? The charter is very clear on this.

The PS already insists on the importance of leveraging existing 
protocols. As far as prefix delegation is concerned, the fact that the 
topology is dynamic brings issues regarding using existing prefic 
delegation mechanisms. So the PS states that these issues should be 
looked at.

> e.g. just after startup MN and in a Standalone MANET.

I agree. Thus the definitions are tighter in -02.

> security issue would solve collisions also. Or it shall be described why

We must be careful not to go in the solution space. What we are trying 
to do here is describing the taxonomy of problems and scenarios that are 
of interest.

>>>> router can lead to non-optimal paths followed by inbound/outbound

I think talking about addresses and prefixes without talking about how 
it impacts on routing is nonsense. The whole Internet architecture is 
based on a precise relationship between prefix<=>location<=>routing. So 
I think we have to mention the potential impact of ill address/prefix 
configuration in this document.

> Text on Deployment Scenarios should be taken out and inserted in the MANET

I do not agree. Again, this document is supposed to describe the 
taxonomy of problems and scenarios that are of interest, and to define 
the terminology in order to do so.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Nov 2007 13:03:46 +0100

> prefix delegation").  I may misunderstand you.
Why not reusing IPv6? Or UDP? ;-)
Of course, we shall reuse what we already have. When there are problems, and
only then, we will write it down. As a next step, we work on a solution.

> Sorry what's MG/LA other than global/local?  M?  A?
;-)
That is why it is important to commonly use terminology.
MLA: MANET Local address (is listed in I-D)
MGA: you can find out yourself...

> any address is correct in a topology changing to follow it.
No, it is not. That is the problem.
MGA are unique in MANET and may be used for intra-MANET traffic.
But for traffic with CNs, a topologically correct addresses must be used.
You are right on topology changing in MANET, this introduces the problem!

> changes with a overlay stable L3 topologies?  Or vice-versa?  Or none?
We are in IETF here and discus Internet and IP related issues. When L2
mechanisms hide mobility, that's fine. When not, we (IETF) have a problem.

> L3 topology be stable over a fixed L2 topology vs L3-variable/L2-
O no!!! Obstacles may move also.
I have lots of experience with this, my test environment is spread over
multiple buildings and we do not have to move MN for frequently topology
changes;-) Some strange guys sit in iron object to go from A to B. Sometimes
they are delivering something to us and block some links for a long time.
Tests may be not reproducible but very similar to real world.

>   And if this is a typical deploying scenario then we're all happy.
If one has also WiMAX or 3G, and there is some delivery using these iron
objects, traffic flows could swap to the other BR. Nice if we could use this
technology, isn't it?

> But is this a relevant scenario, pertinent from market perspective -
Typed in this scenario above.
I do not see any reason not supporting this. Or be aware of the problem. If
it is not needed in some cases, OK. But writing this down in a problem
statement is the first thing we shall do.

> because they use ppp/dhcp/L2IPaddressassignment.
Please stick to MANET related topics.
And please don't focus on technology. We are in IETF and produce protocols
that are adaptive for all these lower layer technologies.

> understand the requirements.
Alex:
Please read MANET Architecture.
And RFC4861 Appendix B: (RFC2461 is OK) 
    o Adding additional procedures for links where asymmetric and non-
      transitive reachability is part of normal operations.  Such
      procedures might allow hosts and routers to find usable paths on,
      e.g., radio links.
And RFC4862 3. Design Goals (RFC2462 is OK).
And RFC4429 Appendix A. Probability of Collision

> default route meaningful and work overall in the presence of topology
Not in scope for Autoconf. 
I thought we agreed on having a PS aligned with the Charter? (your text;-)

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Nov 2007 13:22:34 +0100

Hi Emmanual.
Comments inline.
Teco.

> charter. I
First, declare the two issues.
PS draft:
   Address assignment  - The process of configuring a generated address
      on an interface
   Prefix delegation  -   ???????
I think I have a different idea what prefix delegation is.

I'll comment on this in -02.

> list of
Partly agree. But please do not reinvent the wheel. The Autoconf is solving
problems with RFCs2462/RFC2461 for MANET, nothing more. And all additions on
these could be used, is applicable. If we forget verifying there is a
problem to solve, we are forgetting something.
I do not agree this is solution space. Not at all.

> it impacts on routing is nonsense.
That is what I am saying also.

> The whole Internet architecture is
Yes. But asymmetry in inbound/outbound is a generic issue and not related to
Autoconf. Or am I missing something?

> the terminology in order to do so.
Describing something twice is of no use. I think both Autoconf documents
shall be checked on completeness and redundancy. General MANET architecture
and related issues should be described in the MANET Architecture document. I
think Deployment Scenarios is MANET Architecture and not Problem Statement,
although this is a minor issue.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Nov 2007 14:38:40 +0100

Teco,

Teco Boot wrote:
>>> delegation mechanisms can be used. So why invent something that
>>> can be reused? The charter is very clear on this.
>> Err... I'm agreeing with you to have a PS aligned with the Charter.
>>  But I don't understand: do you disagree reusing DHCP PD? ("NOT
>> work on prefix delegation").  I may misunderstand you.
> Why not reusing IPv6? Or UDP? ;-) Of course, we shall reuse what we
> already have. When there are problems, and only then, we will write
> it down. As a next step, we work on a solution.

Reuse DHCP when doing address autoconf.

Reuse UDP when transporting data.

Reuse both.

In what is DHCP/UDP lacking features necessary to AUTOCONF?  (please 
don't direct me to MANET WG)

>>> G=global). I think problems for the two types are very different,
>>> as MGAs must be globally routable and topologically correct and 
> ;-) That is why it is important to commonly use terminology. MLA:
> MANET Local address (is listed in I-D) MGA: you can find out
> yourself...

Sorry.  I've tried to figure out myself before questioning you.  And I 
started searching MGA and there wasn't.  I should have started searching 
MLA (which sounds surprisingly tongue twisting LMA of netlmm btw).

Thus, I think maybe the PS terminology could define MGA in addition to 
MLA - it would have been clearer to one reader.

>>  strong assumption in MANETs is that the topology changes.  In a
>> sense any address is correct in a topology changing to follow it.
> No, it is not. That is the problem. MGA are unique in MANET and may
> be used for intra-MANET traffic. But for traffic with CNs, a
> topologically correct addresses must be used. You are right on
> topology changing in MANET, this introduces the problem!
> 
> 
> We are in IETF here and discus Internet and IP related issues. When
> L2 mechanisms hide mobility, that's fine. When not, we (IETF) have a
> problem.

Can we detail the when not case?

I know of some MANET testbeds where the L2 hides mobility from L3, and 
that's with WiFi laptops and pdas.

Can we describe a case MANET where L2 doesn't hide the mobility to L3?

>> I think the problem (and solution) is very different if we consider
>> the L3 topology be stable over a fixed L2 topology vs
>> L3-variable/L2- variable.
> O no!!! Obstacles may move also. I have lots of experience with this,
> my test environment is spread over multiple buildings and we do not
> have to move MN for frequently topology changes;-) Some strange guys
> sit in iron object to go from A to B. Sometimes they are delivering
> something to us and block some links for a long time.

Can we describe this scenario in the Scenarios section?  It sounds 
intriguing to me, and if we try to describe it in draft then people may 
chime in and share your views.

>> moving around wifi range, but keeping their L2 and L3 topologies 
>> stable, then the obvious solution is DHCPv6-PD there's no need of
>> anything else. And if this is a typical deploying scenario then
>> we're all happy.
> If one has also WiMAX or 3G, and there is some delivery using these
> iron objects, traffic flows could swap to the other BR. Nice if we
> could use this technology, isn't it?
> 
> 
>> Internet-connects then we can have a whole different set of
>> solutions. But is this a relevant scenario, pertinent from market
>> perspective - question mark.
> Typed in this scenario above. I do not see any reason not supporting
> this.

If needed, I can describe this scenario in the Scenarios section of the
PS document.

> Or be aware of the problem. If it is not needed in some cases, OK.
> But writing this down in a problem statement is the first thing we
> shall do.
> 
> 
>> detailed enough, and too theoretical.  For example they only
>> briefly mention "emergency network", "UMTS", "WiMAX" at the end of
>> sections. And there are so many ways and types deployed of
>> emergency networks and umts and wimax where there's no problem of
>> address auto-configuration - because they use
>> ppp/dhcp/L2IPaddressassignment.
> Please stick to MANET related topics. And please don't focus on
> technology. We are in IETF and produce protocols that are adaptive
> for all these lower layer technologies.

???

What's MANET?

This is not a rhetorical question.  This simply says I don't personally 
understand the word MANET in a sense that could lead to a special IP 
mechanism.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Nov 2007 14:43:55 +0100

Hi Emmanuel,

On not mentioning Solution Space, I do not like the introduction of Internet
Configuration Provider right now.
For Border Router, I roughly what this is, although the discussion is on a
specific border router connecting a MANET to the Internet and a border
router connecting two MANETs, without Internet Connectivity.

I think Autoconf has only to deal with MANETs connected to Internet.
Standalone MANETs are of less interest of IETF, and especially the Internet
Area. So for me, a Border Router is a router connecting a MANET to the
Internet.

Minor issue with term Internet. When a MANET is connected to Internet, it is
immediately part of the Internet. 
Then, a router at the bottom can be used as Border Router for a lower level
MANET. So be careful when defining terminology for Internet and Border
Router.

Teco.

> -----Oorspronkelijk bericht-----
> Van: Emmanuel Baccelli [mailto:[email-masked]]
> Verzonden: vrijdag 16 november 2007 12:19
> Aan: [email-masked]
> Onderwerp: [Autoconf] new version draft-ietf-autoconf-statement-02
> (pre-release)
> 
> Thanks for the feedback. Here's an updated version of the PS taking
> into account recent comments by Thomas and Teco. Aside from fixing
> various editorial details that they pointed out, the main upgrades
> concern:
> 
> 
> * the tightening of the definition/use of "prefix" and "address"
> related terms.
> 
> * more precision in relating to existing protocols' scope as well as
> the one of the protocols-yet-to-be-designed.
> 
> * updated references
> 
> 
> 
> I encourage everyone to continue the public reviewing and discussions
> on this updated basis, until it is published (the plan is to submit
> soon ;)
> 
> 
> Cheers,
> 
> Emmanuel
> 
> 
> 
> 
> Teco Boot a écrit :
> > All,
> >
> G=global). I
> can

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Nov 2007 14:56:04 +0100

Teco Boot wrote:
[...]
> Minor issue with term Internet. When a MANET is connected to 
> Internet, it is immediately part of the Internet. Then, a router at 
> the bottom can be used as Border Router for a lower level MANET. So 
> be careful when defining terminology for Internet and Border Router.

Do we have an RFC definition of the Border Router term?  I know of Area
BR (ABR in ospf) and  ASBR (Autonomous System Border Router).  But is 
there a short English  "Border Router" term defined in an RFC? (don't 
direct me to manufacturer manuals or Wikipedia in German :-)

If yes then let's reuse.  If not then let's define.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Nov 2007 15:04:42 +0100

Alex, comments inline.
Teco.

> don't direct me to MANET WG)
No, I won't direct you to MANET WG. This info shall be included in the
Autoconf PS.
If you can't find it, post this as comment on ML.

> Can we detail the when not case?
Yes, this is described in MANET Architecture.

> chime in and share your views.
Flapping links is common in wireless technologies.
I think the MANET Architecture document describes wireless likes quite good,
although it has some abstraction level. I prefer this abstraction level and
not zoom into details.

> understand the word MANET in a sense that could lead to a special IP
Maybe there are multiple definitions. In Autoconf context, it is well
defined in MANET Architecture.

---

From: "Simone Ruffino" <[email-masked]>
Date: Fri, 16 Nov 2007 15:06:03 +0100

Hi all,
some quick comment below. Generally, I agree with Emmanuel.

mytwocents.

Regs,
Simone

> delegation mechanisms. So the PS states that these issues should be 
I might add that PS clearly specifies (many times) that the goal of an 
autoconfiguration mechanism (not of a prefix delegation mechanism) IS 
address assigment AND prefix delegation.

> I agree. Thus the definitions are tighter in -02.
Manet Local Address has a precise meaning within a MANET and, hence we 
need its definition. Instead, a IPv6 Global Address still remains a IPv6 
Global Address within a MANET, so I don't think a new definition is 
really needed. I'm afraid it generates more confusion...
> to do here is describing the taxonomy of problems and scenarios that 
> are of interest.
Absolutely agree!  Many times in the past we (authors) tried to include 
more details of the problems any single solution (e.g. prefix delegation 
with DHCP) might have. It was agreed, IIRC, that was out-of-scope and we 
were required to focus only on the problem.

Moreover, don't other contributions to this WG (I'm talking about Carlos 
work) provide some sort of gap analysis of current methods ? I 
definitely think that gap analysis should be carried out separately, 
also to speed up WG work.

>> How can a device changes its MANET border router attachment? 
Teco, I agree that the word 'attachment' is not fully appropriate here, 
because it reminds of one-hop radio attachment (this word is frequently 
used in cellular networks). I also suspect that 'device' here is wrong: 
it should be 'MANET router'.

In our minds, a MANET router X is 'attached' to a border router Y, if 
prefixes used by X have been delegated by Y. Hence, packets flowing from 
the Internet to the MANET router X are injected in the MANET by border 
router Y.

To answer your question : a MANET border router can abruptly disappear 
from the MANET, as any other MANET router. In a MANET where multiple 
MANET border routers are available and active (I mean, they're 
delegating valid prefixes), MANET routers can immediately use a new 
prefix coming from a new border router.
>> OK, it can
That is a good point, which I personally support and which covers both 
routing AND addressing, in my opinion.

Currently, we make no assumptions on Ingress Filtering on MANET border 
routers, as well as on any other characteristics Border Router might 
have. Now, in a MANET with multiple border routers, ingress and egress 
routers can be different and problems like the one you mentioned could 
arise.

In fact, when MR chooses a prefix, among those received, it consequently 
decides which border router will receive its traffic from the outside: 
hence, it decides its ingress border router. But, AFAIK, ingress border 
router (for a particular MR) could differ from the egress border router 
(for that particular MR), which is usually indicated by the routing 
protocol.

In my opinion, this is a sort of "cross-issue" that can impact routing, 
addressing mechanism, source address selection. I think it should not be 
excluded from the scope of AUTOCONF WG and in particular from this I-D.

>>>>> router can lead to non-optimal paths followed by inbound/outbound
My previous comment applies here too. In my opinion it has do with 
addressing too, since, in MANET case, an unwise addressing mechanism can 
have severe impacts on performance of applications running on MANET 
routers, or on hosts attached to them.

> based on a precise relationship between prefix<=>location<=>routing. 
> So I think we have to mention the potential impact of ill 
> address/prefix configuration in this document.
>
>
Agree with Emmanuel. We discussed this long ago. Deployment scenarios 
are useful to describe characteristics of scenarios in which autoconf 
mechanism have to work and hence they are functional to the PS 
definition. For example, dynamic scenarios where mobile phones connect 
to the Internet through a cellular network.

--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 16 Nov 2007 15:07:53 +0100

Hi Alex,

> MLA - it would have been clearer to one reader.

There is no sense in the term MGA. What does it mean: MANET+Global? I 
don't understand. Instead in PS-02, we just talk about and define global 
addresses and prefixes. It makes sense and it is enough to be precise.

> chime in and share your views.

This scenario is already included. We are talking about dynamic 
topology, coming from mobility but of course also from the versatility 
of the wireless medium!

> If needed, I can describe this scenario in the Scenarios section of the

Can you tell me how exactly this scenario is not considered by the PS 
now? We are considering this as a special case of the Connected MANET or 
the Standalone MANET depending on what is the external connectivity of 
the case you describe. Please try to check if the scenarios you are 
envisionning are relevant in the sense that they create a case that is 
cannot be mapped in the taxonomy described in the PS.

Emmanuel

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 16 Nov 2007 15:16:30 +0100

Alexandru Petrescu a écrit :
> Teco Boot wrote:
> [...]
>> Minor issue with term Internet. When a MANET is connected to Internet, 
>> it is immediately part of the Internet. Then, a router at the bottom 
>> can be used as Border Router for a lower level MANET. So be careful 
>> when defining terminology for Internet and Border Router.
> 

I agree. There is no definition as far as I know. So this is why the 
term ICP (internet configuration provider) came up in -02. Because all 
we care about in the context of MANET autoconf is where to get 
configuration from. Nothing else.

Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Nov 2007 15:25:45 +0100

> If yes then let's reuse.  If not then let's define.
I don't speak German very well, I'm Dutch;-)

Border Router (BR)
      A border router participates in multiple routing domains, and
      often multiple routing protocols.  A BR defines the border between
      its multiple routing domains.  A BR is responsible for presenting
      a consistent picture of the nodes reachable through itself to each
      routing domain.  A BR determines the routing information to
      propagate between different routing domains.
http://www.ietf.org/internet-drafts/draft-ietf-autoconf-manetarch-07.txt
Print this and put it under your pillow;-)
Tomorrow (or next week) I expect no questions anymore, where answers can be
found in this document.

Cheers, Teco

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Nov 2007 15:51:26 +0100

> addresses and prefixes. It makes sense and it is enough to be precise.
Let me try to explain.
On fixed networks (or where mobility is hidden already), current mechanisms
apply and there is no need for improvement.
In a MANET, there are problems. If there were no problems, we can stop
Autoconf.

MGA are special, because they are generated in a way that is applicable for
MANET. Not all Global Unique Address generation mechanisms are applicable
for MANET, but ALL MGA address generation mechanism are applicable:-). We
just have to work out which are applicable.

A Border Router (or BR related function, as suggested) could very well make
differences in Global Addresses and MGA, for example MGA could require
roaming, e.g. using MIP functionality. For Global Addresses not being MGA,
there is no need for this. 

Think of Home Address (HoA). This is also a special Global Address. Global
Address is not HoA.
Same for CoA.
See RFC3753 for details, please read this before reacting.

I think it is needed for understanding Autoconf problems to use clear
definitions.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Nov 2007 16:06:48 +0100

> address assigment AND prefix delegation.

Can you refer to Autoconf charter?

Teco

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 16 Nov 2007 16:12:30 +0100

> there is no need for this. 

You are right into the solution space. For a specific solution, why not? 
But as far as the problem statement is concerned, this orientation is 
not appropriate.

Emmanuel

---

From: "Simone Ruffino" <[email-masked]>
Date: Fri, 16 Nov 2007 16:12:27 +0100

Teco,
ok, I did not get your point initially. Yes, PS talks about prefix 
delegation and charter not. I think this is because charter does not 
reflect yet improvements (and terminology) introduced with the work on 
MANET architecture.

However, as per address assignment, I see no misalignment.

Simone

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Simone Ruffino" <[email-masked]>
Date: Fri, 16 Nov 2007 16:14:10 +0100

Agree with Emmanuel.
Simone

Emmanuel Baccelli wrote:
> You are right into the solution space. For a specific solution, why 
> not? But as far as the problem statement is concerned, this 
> orientation is not appropriate.
>
> Emmanuel
>
>

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Nov 2007 16:22:46 +0100

Emmanuel Baccelli wrote:
> * the introduction in the terminology section of the term ICP, 
> standing for Internet Configuration Provider, lifting an ambiguity 
> about border routers' potential funtionalities in MANETs.
> 

Here are some technical comments about DHCP and (IPv4 and) IPv6
link-local addresses that could satisfy AUTOCONF needs.

>  case in MANETs (see [2]).

Do you think the link-layers making up MANETs don't have a
broadcast/multicast structure?  I believe the contrary.  All the
wireless link-layers I've played with do have a certain defined
multicast/broadcast behaviour, and act according to these specs.

MANETs made up of Bluetooth, WiFi and WiMAX all have a very defined
multicast behaviour.

What are the wireless links on which you think broadcast will not reach
every host on the subnetwork?  Are you sure you have configured properly
that link-layer?

> For example, in Fig. 1, the MANET router MR3 cannot communicate 
> directly with a DHCP server [4] that would be available through a 
> MANET border router, since the server and the MANET router are not 
> located on the same logical link.  While some DHCP extensions (such 
> as the relay-agent [11]) overcome this issue in a static network, it
>  is not the case in a dynamic topology, as explained below.

Relay is not an extension of DHCP it's builtin since long ago,
implementations.

> for most MANET routers (see [1]).

Are they mobile at physical-layer, link-layer or network-layer?

Neighbor sets in terms of ND?

I would say that a significant proportion of the routers in the MANET
are mobile at physical layer, little at MAC layer and not at all at IP
layer and all works.

> For instance, in Fig. 1, even if MR1 would be able to delegate 
> prefixes to MR3 with DHCP [4], it cannot be assumed that MR1 and MR3
>  will not move and become unable to communicate directly.

This is much misunderstanding for me.

DHCP can not work either  when two servers in a big fixed server farm
have had their cables disconnected by some unknown reason.

If we have had a commonly agreed model of mobility, at least at level
IP, then we could talk about its frequency of change and how DHCP
doesn't support it.  But I can tell from practice that some DHCP
implementations are very reliable to accomodate such changes in wireless
link-layer behaviour.

DHCP has many specified messages to deal with Client loosing its
connectivity, even with the Server shutdown (saves leases in a file).

> autoconfiguration mechanisms in use (see [2]).

I know that DHCPv6 does prefix delegation in order for a houselhold
network to "merge" into ISP's network.  This happens smoothly.  In IPv4
people merged networks many times with NAT and Application-Level Gateways.

My PDA+laptop using IPv4 link-local addresses get merged into a hotspot
very seamlessly.

> autoconfiguration mechanisms (see [2]).

What _is_ network partitioning other than not having been considered in
the design of traditional solutions?  How do networks partition themselves?

> Examples of related issues include cases such as a standalone MANET,
>  whereby connection to the infrastructure is not available, possibly
>  due to network partitioning and loss of connectivity to a MANET 
> border router.  The MANET must thus function without traditional 
> address allocation server availability.  While stateless protocols 
> such as [5] and [3] could provide IP address configuration (for MANET
>  interfaces, loopback interfaces), these solutions do not provide any
>  mechanism for allocating "unique prefix(es)" to routers in order to
>  enable the configuration of host interfaces.

I'm sorry, but have you checked the number of devices that run DHCP
Servers even if when they're disconnected from the Internet?

Or the auto-generation of IPv4 link-local address?  This is obvious
things one thinks about... not even mentioned in the draft.

> MANET Autoconfiguration Goals
> 
> A MANET router needs to configure IP addresses and/or prefixes on its
>  non-MANET interfaces.  In addition, it needs to configure a link 
> local address, a /128 and/or an MLA on its MANET interface.

Why would it configure a MLA if it had a ll and a global?  Why are the
global address and the link-local addresses insufficient?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Nov 2007 16:24:03 +0100

Emmanuel Baccelli wrote:
> Hi Alex,
> 
> 
>>>>> Then I want descriptions of problems with MLA and MGA 
>>>>> (L=local, G=global). I think problems for the two types are 
>>>>> very different, as MGAs must be globally routable and 
>>>>> topologically correct and generation has to do with Border 
>>>>> Routers.
>> Sorry.  I've tried to figure out myself before questioning you. And
>>  I started searching MGA and there wasn't.  I should have started 
>> searching MLA (which sounds surprisingly tongue twisting LMA of 
>> netlmm btw).
>> 
>> Thus, I think maybe the PS terminology could define MGA in addition
>>  to MLA - it would have been clearer to one reader.
>> 
> 
>  don't understand. Instead in PS-02, we just talk about and define 
> global addresses and prefixes. It makes sense and it is enough to be 
> precise.

But somehow MLA (MANET Local Address) could lead to confusions about
link-local addresses.

(manet-iana defines a link-local multicast group - is an MLA that
  group?)

>>>> It's strange to talk about topologically correct addresses when
>>>>  the strong assumption in MANETs is that the topology changes. 
>>>> In a sense any address is correct in a topology changing to 
>>>> follow it.
>>> No, it is not. That is the problem. MGA are unique in MANET and 
>>> may be used for intra-MANET traffic. But for traffic with CNs, a
>>>> Or maybe one AUTOCONF requirement is to support dynamic L2 
>>>> topology changes with a overlay stable L3 topologies?  Or 
>>>> vice-versa?  Or none?
>>> We are in IETF here and discus Internet and IP related issues. 
>>> When L2 mechanisms hide mobility, that's fine. When not, we 
>>> (IETF) have a problem.
>> 
>> I know of some MANET testbeds where the L2 hides mobility from L3, 
>> and that's with WiFi laptops and pdas.
>> 
>>>> I think the problem (and solution) is very different if we 
>>>> consider the L3 topology be stable over a fixed L2 topology vs
>>> O no!!! Obstacles may move also. I have lots of experience with 
>>> this, my test environment is spread over multiple buildings and 
>>> we do not have to move MN for frequently topology changes;-) Some
>>>  strange guys sit in iron object to go from A to B. Sometimes 
>> intriguing to me, and if we try to describe it in draft then people
>> may chime in and share your views.
> 
> topology, coming from mobility but of course also from the 
> versatility of the wireless medium!

Emmanuel - I think you go too fast to describe that Teco scenario as
already being part of the autoconf-statement scenarios.

I think it's not clear what the Teco scenario with iron objects is, for
a start.  His scenario seems to be completely static with a tank MN and
fixed buildings (by that description I think it can easily be
accomodated with DHCP.)  Whereas the autoconf-statement scenarios
describe movements (joining, partition, merging, mobile users).

>>>> For example, if we consider a MANET to be a set of PDAs 
>>>> physically moving around wifi range, but keeping their L2 and 
>>>> L3 topologies stable, then the obvious solution is DHCPv6-PD 
>>>> there's no need of anything else. And if this is a typical 
>>>> deploying scenario then we're all happy.
>>> If one has also WiMAX or 3G, and there is some delivery using 
>>> these iron objects, traffic flows could swap to the other BR. 
>>> Nice if we could use this technology, isn't it?
>>> 
>>> 
>>>> If on the other hand we consider a MANET to be a 
>>>> pda+laptop+phone personal set dynamically changing the way it 
>>>> intra-connects and Internet-connects then we can have a whole 
>>>> different set of solutions. But is this a relevant scenario, 
>>>> pertinent from market perspective - question mark.
>>> Typed in this scenario above. I do not see any reason not 
>>> supporting this.
>> 
>> If needed, I can describe this scenario in the Scenarios section of
>>  the PS document.
> 
>  now?

My scenario is user oriented, issued from a user experience, with a
potential benefit to be offered to a user in a perceptible way.

> We are considering this as a special case of the Connected MANET or 
> the Standalone MANET depending on what is the external connectivity 
> of the case you describe.
> 
> Please try to check if the scenarios you are envisionning are 
> relevant in the sense that they create a case that is cannot be 
> mapped in the taxonomy described in the PS.

I will check but I don't think it does.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Nov 2007 16:28:48 +0100

> However, as per address assignment, I see no misalignment.

I think Prefix Delegation is solution space.

You could check:
draft-bernardos-autoconf-solution-space-00.txt, 4.2.  What type of IP
delegation: addresses or prefixes?
 
And I wonder after MANET address assignment problems are solved, what
problems with current prefix delegation protocols are left. 

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Nov 2007 16:34:09 +0100

> not?

Second one was example and yes, you are correct, this is solution space.
First part of the text is problem space. Once again, we need to verify what
current mechanisms are applicable for MGA. We won't spend a minute on
research on what is applicable for GA. That is a large, large difference.

Teco.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 16 Nov 2007 16:40:49 +0100

> describe movements (joining, partition, merging, mobile users).

Do you want to describe exhaustively every scenario? If this iron object 
is a car, or if it is a tank? Or if it is a tea pot? I think this is not 
reasonnable. I think the problem statement has a clear taxonomy of 
scenarios, and I have yet to understand why the specail cases you 
mention cannot be mapped into the categories that are already outlined.

Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Nov 2007 17:08:18 +0100

Emmanuel Baccelli wrote:
>> Emmanuel - I think you go too fast to describe that Teco scenario
>> as already being part of the autoconf-statement scenarios.
>> 
>> I think it's not clear what the Teco scenario with iron objects is,
>> for a start.  His scenario seems to be completely static with a
>> tank MN and fixed buildings (by that description I think it can
>> easily be accomodated with DHCP.)  Whereas the autoconf-statement
>> scenarios describe movements (joining, partition, merging, mobile
>> users).
>> 
> 
> Do you want to describe exhaustively every scenario? If this iron
> object is a car, or if it is a tank? Or if it is a tea pot? I think
> this is not reasonnable. I think the problem statement has a clear
> taxonomy of scenarios, and I have yet to understand why the specail
> cases you mention cannot be mapped into the categories that are
> already outlined.

It appears too exhausting to describe each and every scenario, right :-) 
They look as easily mapped from one to another.  They're all networks in 
the end :-)

Alex

---

From: Thomas Clausen <[email-masked]>
Date: Fri, 16 Nov 2007 17:35:25 +0100

On 16Nov , 2007, at 3:51 PM, Teco Boot wrote:

>> global

Agreed. This is precisely the notion that is intended with the MANET  
architectural model, and which I find appropriate -- or else we'd be  
"redesigning the internet" or something. Do not want to do that.

> just have to work out which are applicable.

Teco, I think that you are right on the money in the above. I think  
it captures nicely the distinction of "manet" and "! manet"

> See RFC3753 for details, please read this before reacting.

I am not sure that I agree with the *requirement* to make a  
difference between MGAs and "other GAs", but I do agree that there is  
value in considering it and -- as you indicate -- understanding the  
rationale behind e.g. 3753.

-- 
Thomas Clausen
[email-masked]
http://www.thomasclausen.org/
http://hipercom.thomasclausen.org/

---

From: Thomas Clausen <[email-masked]>
Date: Fri, 16 Nov 2007 17:45:32 +0100

I disagree. See below....

>>> just have to work out which are applicable.

At first sight, one could say "yes" to the above without blinking.  
But, there are a number of points that could be made and which are  
complementary. In simple terms:

	o MGAs are generated in a way that is applicable for MANET -- yes.

	o an interface with any "normal" Global Unique Address is "normally"
	   communicating (directly or via a tunnel) to the upper router from
	   which it got the address and with respect to which this global  
address
	   is topologically correct (this is what NEMO, MobileIP goes out of  
the way
	   to ensure -- for good reasons, one of which being ingress filtering)

	o an interface with a MGA *MAY* actually use that MGA bit communicating
	   to an upper router from which it did NOT get the address and with  
respect
	   to which the address is not topologically correct (remember: one  
does not
	   normally assume static hierarchies in MANETs, but things can move  
around
	   -- and the PS I-D talked about a "border router" of sorts handing  
out
	   addresses). As such, and with respect to MGAs, ingress-filtering  
*MAY*
	   be impacted

	o .....or not, depending (obviously) on how one views the problem.  
But, this
	   is then the crux of the PS I-D, is it not? To state the problem  
as we see it?

This is simplified -- but the point is to encourage that we do not  
disregard this viewpoint without carefully considering it first.

>> You are right into the solution space. For a specific solution,  
>> why not? But as far as the problem statement is concerned, this  

As I read Teco's comment, the "could very well" bit means "maybe we  
should think about this at this point" -- which I agree that we should.

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Nov 2007 17:50:42 +0100

Thomas, hi,

Thomas Clausen wrote:
>>> There is no sense in the term MGA. What does it mean:
>>> MANET+Global? I don't understand. Instead in PS-02, we just talk
>>> about and define global addresses and prefixes. It makes sense
>>> and it is enough to be precise.
>>> 
>> Let me try to explain. On fixed networks (or where mobility is
>> hidden already), current mechanisms apply and there is no need for
>> improvement. In a MANET, there are problems. If there were no
>> problems, we can stop Autoconf.
>> 
> 

If you don't want to redesign the way in which addresses are assigned
with respect to how routing works I'm afraid there's no much problem to
be solved here, IMHO.

I mean - if you want to design a new mechanism to assign an address to a
host whose network will subsequently change its routing such us to be
able to route towards it - then this may involve some requirements that
can be laid down, problem written, etc.

But, if you want to design a new mechanism to assign an address to a
host whose network is pre-planned an addressing architecture - then I
think there's no problem here to be solved.  I think we could list the
existing mechanisms allowing us to achieve that address assignment:
link-local address formation, DAD, stateless, BOOTP, DHCP.  I'm not
seeing those listed in these documents although they're really
widespread use in the networks I see.  Why aren't they listed?
Sometimes I think they've all been considered but discarded.  Other
times I think they haven't even been considered.

Maybe, IMHO, maybe just, if one has a very specific scenario (very well
described and agreed) then one may find some drawbacks to DHCP: for
example between a PDA and a laptop who wants to be the Server?  Or who's
the Router?  And then improve DHCP or stateless for _that_ scenario.  Or
go to DHC WG and MAN WG and improve these there.  But I don't see such
detail scenario described here.

We don't even agree what to reuse :-(

Alex

>> MGA are special, because they are generated in a way that is 
>> applicable for MANET. Not all Global Unique Address generation
>> mechanisms are applicable for MANET, but ALL MGA address generation
>> mechanism are applicable:-). We just have to work out which are
>> applicable.
>> 
> 
>> A Border Router (or BR related function, as suggested) could very
>> well make differences in Global Addresses and MGA, for example MGA
>> could require roaming, e.g. using MIP functionality. For Global
>> Addresses not being MGA, there is no need for this.
>> 
>> Think of Home Address (HoA). This is also a special Global Address.
>>  Global Address is not HoA. Same for CoA. See RFC3753 for details,
>> please read this before reacting.
>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 16 Nov 2007 18:00:36 +0100

> I think Prefix Delegation is solution space.

Prefix delegation is not a solution but rather the base of IP addressing 
in general. So I guess we are  inside this framework for now, whether we 
want it or not.

Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Nov 2007 18:58:20 +0100

>   respect to which the address is not topologically correct (remember:
>   one does not normally assume static hierarchies in MANETs, but things
can
>   move around -- and the PS I-D talked about a "border router" of sorts
>   handing out addresses). As such, and with respect to MGAs, ingress-
>   filtering *MAY* be impacted

I assume within a MANET there is no ingress filtering.
Correct? 
Write down somewhere?

Filters implemented with RPF checks are less harmful. But there is a problem
here, I explained the relation between address generation and routing
convergence before.

Bytheway, I do not like this hierarchical prefix delegation mechanism, for
reasons that the mechanisms breaks when topology changes. No problem for
inner MANET communication, but how can we facilitate communication with the
outside? I think it can be used only for MLA and not for MGA. We need both,
isn't it?

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Nov 2007 19:10:10 +0100

> Verzonden: vrijdag 16 november 2007 18:01
> Aan: [email-masked]
> Onderwerp: Re: [Autoconf] Review of draft-ietf-autoconf-statement-01
> 
> 
> 
> Teco Boot a écrit :
Ok for /128 prefix delegation.
I you want to take care of all IP addressing issues, I wish you good luck.
I want an Autoconf solution available soon. Focusing on the charter and the
real word problems helps.
As mentioned before, I am not against PD. It is out there already and I
think it can be reused immediately as soon as we have the address assignment
(and routing) solved. Or please specify why not.
Routing is out-of-scope for Autoconf.
Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Nov 2007 20:47:44 +0100

Emmanuel Baccelli wrote:
> 
> 
> Teco Boot a écrit :
>>> ok, I did not get your point initially. Yes, PS talks about 
>>> prefix delegation and charter not. I think this is because 
>>> charter does not reflect yet improvements (and terminology) 
>>> introduced with the work on MANET architecture.
>>> 
> Prefix delegation is not a solution but rather the base of IP 
> addressing in general. So I guess we are  inside this framework for 
> now, whether we want it or not.

I was reading this and thought we finally agree on DHCP-PD should be
used :-)

But then I doubt you really meant what I thought you meant.

I think you mean that prefixes are delegated from one place to another,
at an administrative level (and not necessarily DHCP-PD), and thus a
basis of IP addressing in general.  I think that because the
autoconf-manetarch draft uses "A MANET router can be delegated zero or
more prefixes" (if it meant what I thought it meant then we'd no longer
question the use of DHCPv6-PD).

I have this doubt also because autoconf-statement draft says "Therefore,
network topology may change rather dynamically compared to traditional
networks, which invalidates traditional delegation solutions that were
developed for infrastructure-based networks, such as [11] [RFC3046] DHCP
Relay-Agent option" (invalidating traditional delegation solutions like
DHCPv6-PD?)

I think autoconf-manetarch draft should not use the term "delegated zero
or more prefixes" if it does not mean DHCPv6-PD.  It should better use
the term "administratively delegated" (as when RIPE delegates a subnet
to some ISP) or some other distinctive text to avoid confusion.

And autoconf-statement draft should better cite RFC 3633 "IPv6 Prefix
Options for DHCPv6" instead of RFC3046 "DHCP Relay-Agent Options" when
talking about delegation, because Relays don't delegate they just
forward and eventually insert options.  A Relay is indeed pre-configured
with a prefix, administratively assigned by some administrator.

This is again terminology, sorry, but without it we may misunderstand
each other very easily.

What do you think?

Alex
PS: I assume we don't talk here DNS delegation of responsibility of
     reverse resolution (although MANET networks should be concerned
     about DNS too and a prefix delegated by DHCPv6 could be accompanied
     by a DNS delegation for reverse resolution of that prefix as well).

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Nov 2007 20:57:51 +0100

Teco Boot wrote:
>> o an interface with a MGA *MAY* actually use that MGA bit 
>> communicating to an upper router from which it did NOT get the 
>> address and with respect to which the address is not topologically 
>> correct (remember: one does not normally assume static hierarchies 
>> in MANETs, but things
> can
>> move around -- and the PS I-D talked about a "border router" of 
>> sorts handing out addresses). As such, and with respect to MGAs, 
>> ingress- filtering *MAY* be impacted
> 
> I assume within a MANET there is no ingress filtering. Correct? Write
>  down somewhere?

In the MANETs I'm concerned about - mostly MANETs where one or two
humans are in charge of all devices connecting - yes.

> Filters implemented with RPF checks are less harmful. But there is a 
> problem here, I explained the relation between address generation and
>  routing convergence before.

I think ingress filtering and RPF checks are popular with Access Routers
where unknown people connect to.  But in the MANETs I'm concerned about
(my laptop is my AR) I'm not concerned about ingress filtering and RPF
checks because I know in advance who and what's going to connect to it.

> Bytheway, I do not like this hierarchical prefix delegation 
> mechanism, for reasons that the mechanisms breaks when topology 
> changes.

What do you mean by the hierarchical prefix delegation mechanism?  Do
you mean DHCPv6-PD?  Or do you mean administratively assign prefixes?

If you mean DHCPv6-PD then it is not hierarchical at all, the prefixes
can be anything the admin puts in the Server's configuration file, not
necessarily in a hierarchical relationship.

Administratively assigning prefixes?  I think at the highest level (from
space to RIPE, from RIPE to ISP and from ISP to some clients) it may
indeed be hierarchical.  But within a MANET (very leaf low-level) I sure
think routing doesn't impose prefixes to be assigned in a hierarchical
manner.

I think I agree with you that a strict hierarchical assignment of
prefixes to (even a fixed) MANET topology makes little sense because the
MANET topology is not necessarily a tree but rather a mesh.  Of course,
one could have a hierarchical tree of prefixes assigned to a mesh
topology, but nothing imposes it to be so.

I think in the MANETs I'm concerned about the IPv6 prefixes are not
hierachically assigned.

That said, I don't see why discarding DHCPv6-PD on hierarchicality
grounds.  But probably you didn't mean to discard DHCPv6-PD?

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Sat, 17 Nov 2007 08:55:03 +0100

> Van: Alexandru Petrescu [mailto:[email-masked]]
> Verzonden: vrijdag 16 november 2007 20:58
> Aan: Teco Boot
> CC: [email-masked]
> Onderwerp: Re: [Autoconf] Re: Scenarios and Requirements
> 
> Teco Boot wrote:
We should look for protocols that can be used also in other environments.
Think about a managed service, where 200 people are responsible.
If we build the protocols just for your scenario, I stop putting effort on
this immediately.
But if we can do it jointly, for multiple scenarios, I am in. I hope same
for you.
Please think about all scenarios.

By the way, I think you are saying that Autoconf is extremely focused on
classical MANET (don't ask, read the manetarch) and not on commonly used
access networks.
I think the current PS misses this issue completely. I call this Border
Router selection. Criteria are the path between MN and BR and also
credentials. Not all border routers accept traffic from everybody. Most ISP
live from paid services.

I would like that some of the ISP guys provide opinions on what the
requirements are. Will ISP ever support MANET? What are the conditions?

> you mean DHCPv6-PD?  Or do you mean administratively assign prefixes?
Again, read the manetarch.
When each MANET Router is DHCP server and client, it can request a prefix,
use some of the space for itself and delegate parts to other MANET Routers.
Deeper in MANET, prefix lengths are becoming longer.

> think routing doesn't impose prefixes to be assigned in a hierarchical
Why not? No one can block it. Maybe we agree this is not a preferred
solution, especially for MGA. For MLA it is fine, although I think there are
other solutions. Maybe better ones.

> grounds.  But probably you didn't mean to discard DHCPv6-PD?
None of existing protocols shall be discarded.
We shall focus on problems with current protocols.
Only when no solution is found, we shall work on a new protocol.

I think MLA can be generated with current mechanisms. Random, hash, DHCP;
whatever you like. There is a relation with PacketBB, for example DHCP (or
another managed mechanism) can provide addresses / prefixes that can be
compressed. The random ones are hard to compress:-((

I think MGA has to do with border router selection. I am not aware of a
selection protocol for this. I have written one down, but I throw away my
idea immediately as soon as I find an existing and appropriate protocol for
this.
Bytheway, I have "stolen" the idea, see my I-D. And when adopted, it shall
be reused as much as possible. E.g. RL2N and MIP.

Cheers, Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 17 Nov 2007 20:11:28 +0100

Teco Boot wrote:
> 
>> -----Oorspronkelijk bericht----- Van: Alexandru Petrescu 
>> [mailto:[email-masked]] Verzonden: vrijdag 16 
>> november 2007 20:58 Aan: Teco Boot CC: [email-masked] Onderwerp:
>>  Re: [Autoconf] Re: Scenarios and Requirements
>> 
>> Teco Boot wrote:
>>>>  address and with respect to which the address is not 
>>>> topologically correct (remember: one does not normally assume 
>>>> static hierarchies in MANETs, but things
>>> can
>>>>  sorts handing out addresses). As such, and with respect to 
>>>> MGAs, ingress- filtering *MAY* be impacted
>>> I assume within a MANET there is no ingress filtering. Correct? 
>>> Write down somewhere?
> We should look for protocols that can be used also in other 
> environments. Think about a managed service, where 200 people are 
> responsible. If we build the protocols just for your scenario, I stop
>  putting effort on this immediately. But if we can do it jointly, for
>  multiple scenarios, I am in. I hope same for you. Please think about
>  all scenarios.

I agree with you.  I'm ready to describe the scenario I'm interested it.
  It involves mainly personal area networks made of PDAs, laptops,
cameras, some sensors may be.  This is just high-level description but
more detail can easily be told.

I would also like to work on reqs for scenarios that you may consider,
with 200 or so people responsible for some devices.  Except that I don't
know how is that described?  What does scenario look like?  What devices
are there?  Are they laptops, pdas, sensors - what are they more exactly?

> By the way, I think you are saying that Autoconf is extremely focused
>  on classical MANET (don't ask, read the manetarch) and not on 
> commonly used access networks. I think the current PS misses this 
> issue completely. I call this Border Router selection. Criteria are 
> the path between MN and BR and also credentials. Not all border 
> routers accept traffic from everybody. Most ISP live from paid 
> services.

You mention very often Border Router - but what is it in the real life?
  What kind of device, what's its main application role - is it a router
in a vehicle?  A headmount display device?  What is it?  What is the
application?

> requirements are. Will ISP ever support MANET? What are the 

I sense the question, but I think ISP people will be more likely to
respond if we asked it differently:

How does an ISP support the set-top box and the wifi phone sold to a
customer?  Do they plan to support IPv6 for this?  Do they see it as a
'MANET'?  How many subnets do they expect the consumer at home to have
for this set-top box + wifi phone?  These are things some ISPs consider
when they design their address architecture.

>>> Filters implemented with RPF checks are less harmful. But there 
>>> is a problem here, I explained the relation between address 
>>> generation and routing convergence before.
>> I think ingress filtering and RPF checks are popular with Access 
>> Routers where unknown people connect to.  But in the MANETs I'm 
>> concerned about (my laptop is my AR) I'm not concerned about 
>> ingress filtering and RPF checks because I know in advance who and 
>> what's going to connect to it.
>> 
>> What do you mean by the hierarchical prefix delegation mechanism? 
>> Do you mean DHCPv6-PD?  Or do you mean administratively assign 
>> prefixes?
>> 
> Again, read the manetarch. When each MANET Router is DHCP server and 
> client, it can request a prefix, use some of the space for itself and
> delegate parts to other MANET Routers. Deeper in MANET, prefix 
> lengths are becoming longer.

This sounds ok to me.  This is a good way to make it work IMHO.

>> If you mean DHCPv6-PD then it is not hierarchical at all, the 
>> prefixes can be anything the admin puts in the Server's 
>> configuration file, not necessarily in a hierarchical relationship.
>> 
>> 
>> 
>> 
>> 
>> Administratively assigning prefixes?  I think at the highest level
>>  (from space to RIPE, from RIPE to ISP and from ISP to some
>> clients) it may indeed be hierarchical.  But within a MANET (very
>> leaf low-level) I sure think routing doesn't impose prefixes to be
>>  assigned in a hierarchical manner.
>  solution, especially for MGA. For MLA it is fine, although I think 
> there are other solutions. Maybe better ones.

YEs, right, no one can block to design a hierarchical architecture
within the MANET.  I wanted to say DHCPv6-PD doesn't force that
hierarchical addressing architecture either (thus not a reason to
discard it).  I think we are in agreement here.

>> prefixes to (even a fixed) MANET topology makes little sense 
>> because the MANET topology is not necessarily a tree but rather a 
>> mesh.  Of course, one could have a hierarchical tree of prefixes 
>> assigned to a mesh topology, but nothing imposes it to be so.
>> 
> None of existing protocols shall be discarded. We shall focus on 
> problems with current protocols. Only when no solution is found, we 
> shall work on a new protocol.
> 
> I think MLA can be generated with current mechanisms. Random, hash, 
> DHCP; whatever you like.

Yes, I agree, and this could be listed as: privacy addresses, DAD,
IPv6-over-foo, IPv6-over-Ethernet, HBA, CGA, DHCP, BOOTP.  I think this
covers all known methods of autoconfiguring and forming addresses.

I yet have to see the need to design a new mechanism to autoconfigure
addresses. (extending one seems ok).

> There is a relation with PacketBB, for example DHCP (or another 
> managed mechanism) can provide addresses / prefixes that can be 

(Don't start me on PacketBB :-)

  PacketBB means of encoding addresses in messages is issued out of a
  _non-agreed_ requirement.  It is pretty unique in the way it does it,
  it's smart, it may reduce wireless consumption (it smartly compresses
  address representation).  But I don't think that's needed.  And if we
  had agreed on a requirement to achieve that compression for a reduction
  in bandwidth consumption there are many other existing mechanisms to
  achieve it.)

> I think MGA has to do with border router selection. I am not aware of
>  a selection protocol for this. I have written one down, but I throw 
> away my idea immediately as soon as I find an existing and 
> appropriate protocol for this.

Sorry, I have to read it first.

Until then here's what comes to my mind: you need the MR to select a BR
to use as its default route?

Use RFC4191 "Default Router Preferences and More-Specific Routes".  It's
a pretty straightforward means for a BR to communicate preferences to
the MR in the Router Advertisements.  I see it fit, why not?  Can we
extend it to adapt it to your scenario?

Otherwise.  If BRs and MRs run all OSPF then a certain MR will always
select the best BR.

Would those two fit the selection you talk about?  Or do they miss
something?  What?  Can we extend them?

> Bytheway, I have "stolen" the idea, see my I-D. And when adopted, it 
> shall be reused as much as possible. E.g. RL2N and MIP.

:-) :-)

Is RL2N Routing for Low Power and Lossy Networks that BoF
http://www.employees.org/~jvasseur/ ?

Your I-D is titled fine but misnames BRDP (Border Router Discovery
Protocol) as a protocol(?)  It's good it looks at ND.  I think less
things could be extended (e.g. avoid AAA use) but I could remark
technically separately on BRDP.  (For example I'd call it better "ND
extensions to achieve..." instead of BRDP.  A new Protocol should
involve new messages, not just extension of existing messages.)  I won't
hijack this thread, let's agree on AUTOCONF scenarios and requirements
in detail first.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Sun, 18 Nov 2007 23:04:11 +0100

> Verzonden: zaterdag 17 november 2007 20:11
> Aan: Teco Boot
> CC: [email-masked]

I think this is more or less similar to NEMO RO use cases, isn't it?
Maybe we should describe were multihop connectivity applies between those
devices and the Border Router, as an extension to the NEMO RO use cases.

> are there?  Are they laptops, pdas, sensors - what are they more

Is this important? By the way, "some devices" would be large numbers. Number
of Border Routers are also large numbers. Think on regional / national /
international access networks with multiple technologies, provided by
multiple ISPs. Assume hotspot, WiMAX, 3G and cabling as last ad-hoc hop to
Border Router. Users are personal, small business, enterprise, NGO, public
safety, military and maybe more. I think it is not important to work out
this kind of details, problems are similar.  

We never described details on laptop, pda, server etcetera when defining IP
protocols.

> in a vehicle?  A headmount display device?  What is it?  What is the

Border Router is described in manetarch, although I want to be more specific
on this. Is it a router between two routing domains or does it provide
access to Internet? The last one is a subset of the first.

>   in bandwidth consumption there are many other existing mechanisms to

Please check BGP.
And reducing overhead in MANET protocol is needed for scalability.
Maybe your personal interest is extreme small ad-hoc setups. My interest is
the opposite. I think we can work out a common solution;-)

> to use as its default route?

The scope for Autoconf is addressing and NOT routing.
But yes, BR selection and routing to that BR and from that BR back to the
node has a strong relationship.

> extend it to adapt it to your scenario?

No, two bits may be enough for selecting an access router on a link. For
MANET we need better metrics.

> something?  What?  Can we extend them?

Autoconf shall be independent of the MANET protocol (charter). We have about
5 already, more dialects to come.
The problem here is when we have a Autoconf protocol, a BR could be selected
but this BR could not be reachable, because it speaks another dialect.

Maybe we should think of decoupling inner-MANET-routing and BR-routing.
Again, this is not Autoconf. We could work on a requirements For Br Routing
document and sent this to the Routing Area. Or discuss this with MANET WG
(and RL2N, after BOF).

> http://www.employees.org/~jvasseur/ ?

Yepp.

> Protocol) as a protocol(?)  It's good it looks at ND.
NDP is a protocol, running on ICMP which is also a protocol, running on IP,
which is also a protocol, running on a lower layer protocol.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Nov 2007 12:11:06 +0100

Hi Teco, let's keep this thread on AUTOCONF Scenarios and Requirements.
  I snipped some parts for this reson.

Teco Boot wrote:
>> [mailto:[email-masked]] Verzonden: zaterdag 17 
>> november 2007 20:11 Aan: Teco Boot CC: [email-masked] Onderwerp:
>>>  responsible. If we build the protocols just for your scenario, I
>>>  stop putting effort on this immediately. But if we can do it 
>>> jointly, for multiple scenarios, I am in. I hope same for you. 
>> I agree with you.  I'm ready to describe the scenario I'm 
>> interested it. It involves mainly personal area networks made of 
>> PDAs, laptops, cameras, some sensors may be.  This is just 
>> high-level description but more detail can easily be told.
> 

I think the scenario with PANs under a single administrator can have a
solution as a MIP6 extensions to RO for NEMO, or a routing protocol
solution - or probably no new protocol at all.

But - yes - it is obvious that we talk very similar scenarios in the
NEMO RO reqs and in MANET reqs and in AUTOCONF reqs.

> Maybe we should describe were multihop connectivity applies between 
> those devices and the Border Router, as an extension to the NEMO RO 
> use cases.

What's multihop connectivity?

>> I would also like to work on reqs for scenarios that you may 
>> consider, with 200 or so people responsible for some devices. 
>> Except that I don't know how is that described?  What does scenario
>>  look like?  What devices are there?  Are they laptops, pdas, 
>> sensors - what are they more exactly?
> 
> Is this important?

Here, in this case, I think it is important to describe the scenarios in
more detail otherwise I'm afraid it's going to lead again to new
mechanisms designed for less purpose.

I personally I'm used to see detail scenario, then see people say how
easily this can be accommodated with existing stuff then other people
say where it failed after experimentation - and so on.

> By the way, "some devices" would be large numbers. Number of Border 
> Routers are also large numbers. Think on regional / national / 
>  multiple ISPs. Assume hotspot, WiMAX, 3G and cabling as last ad-hoc
>  hop to Border Router. Users are personal, small business,
> enterprise, NGO, public safety, military and maybe more. I think it
> is not important to work out this kind of details, problems are
> similar.

Ok, I kind of see, but this still looks too generic.  It pretty much
covers about everything leaf network one can imagine.

I think you may be right to deduce that the problems are similar, but to
me it is too early to say so.

There are fine differences between cases.  Let me tell one difference.
Consider a rescue scene with vehicles in a fixed situation.  Each has a
mobile router within.  Consider one vehicle to the the "Captain" and
using a high-power WiFi Access Point to give DHCP addresses to all other
vehicles.  This is an easy IP configuration scenario which can easily be
accommodated by existing protocols.  But then there may be a requirement
against the existence of that central entity and all vehicles should
communicate with WiFi without Access Point.  Now this is much more
difficult to accommodate with existing IP protocols, because there's
very little structure.  New mechanisms may be needed for this.  Things
may be easier if all vehicles are fixed instead of moving.

But, a big but, who can tell these kinds of requirements?  Can we tell
at least the little requirement that deals with being mobile or not
mobile?  Or the little requirement that tells which applications (or
kinds of) are run?

It may be that we go to customers and they'll say of course there's a
central command and control vehicle, with a central Access Point and
they absolutely need itt.  The reverse may be true too: the scene should
work until command unit arrival too, thus no AP for a while.  Or it may
be that TCP/IP connectivity is less urgent and can wait until that
vehicle arrives.

This kinds of requirements are important.  You can formulate them
however you want, in terms of teapots and spoons (such as to avoid
"tanks") if you want.  But make it intelligible from a protocol
behaviour perspective.

> We never described details on laptop, pda, server etcetera when 
> defining IP protocols.

These people had _very_ strong requirements: they wanted to make remote
computers talk to each other.  That's done.

But here's no requirement in my understanding (sorry if I don't see
something obvious).

[...]

> Autoconf shall be independent of the MANET protocol (charter). We 
> have about 5 already, more dialects to come.

We have 5 whats?  5 MANET protocols?  Or 5 methods for AUTOCONF WG?

Do we have any AUTOCONF solution proposal?

> The problem here is when we have a Autoconf protocol, a BR could be 
> selected but this BR could not be reachable, because it speaks 
> another dialect.

Let's see what an AUTOCONF protocol looks like first, no?

> Maybe we should think of decoupling inner-MANET-routing and 
> BR-routing. Again, this is not Autoconf. We could work on a 
> requirements For Br Routing document and sent this to the Routing 
> Area. Or discuss this with MANET WG (and RL2N, after BOF).
> 
>>> Bytheway, I have "stolen" the idea, see my I-D. And when adopted,
>>>  it shall be reused as much as possible. E.g. RL2N and MIP.
>> 
>> :-) :-)
>> 
> NDP is a protocol, running on ICMP which is also a protocol, running 
> on IP, which is also a protocol, running on a lower layer protocol.

We'll see separately if you want to fork a new thread :-)

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 19 Nov 2007 13:18:56 +0100

Hi Alex,

I put some comments inline.
I think the most important issue you brought up is having Autoconf also
looking at PAN, where devices behind Personal MR cannot autoconfigure MGA.
This use case is missing in autoconf-manetarch. More text on this inline.

Teco.

> Verzonden: maandag 19 november 2007 12:11
> Aan: Teco Boot
> CC: Alexandru Petrescu; [email-masked]

Where there is no direct connectivity between a node and the Border Router,
e.g. gadget to smartphone to 3GPP.
I am not sure we need a full blown MANET protocol for this. But there is a
need for routing. Or nested NEMO. Or both.

I think the Autoconf shall develop a mechanism for providing an address to
the gadget. But gadget does not receive 3GPP RA and thus it cannot configure
an address for it.

> say where it failed after experimentation - and so on.

I agree in focusing on real world problems. But I doubt if we need to write
down this in RFCs.

> vehicles.  This is an easy IP configuration scenario which can easily
> be accommodated by existing protocols.  

Maybe IP config is easy. Providing fully meshed connectivity is a hell.
There could be mountains, buildings or vehicles preventing line-of-sight. Or
the captain takes his vehicle and drives to the mayor. Or other disasters
for good quality radio communication.

When only the captain has high power AP, there will be uni-directional links
- Asymmetric Reachability.

Rescue is not fixed and the problems are far more complex.
Let's save lives and provide something better to the rescue teams.

> But then there may be a
> requirement

It is not new. We have this already. It is called MANET Routing protocol.

> "tanks") if you want.  But make it intelligible from a protocol

I think MANET technology being used is well described in manetarch.
I think there is little need in providing a long list of detailed user
requirements, this will costs lots of time and it brings not that much.

We could think on adding more text in manetarch on non-transitive
communication (X<->Y is OK, Y<->Z is OK, X<->Z is not OK), like your use
case with 3GPP and Bluetooth/UWB.

> We have 5 whats?  5 MANET protocols?  Or 5 methods for AUTOCONF WG?

5 MANET protocols.

> Let's see what an AUTOCONF protocol looks like first, no?

When the Autoconf is independent of the routing protocol and does not
provide a path between nodes and the BR, the BR could be not reachable from
the nodes. Or am I missing something?

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 19 Nov 2007 14:01:02 +0100

Hi Teco.
I still don't understand the term MGA. Can you check if what you mean is 
not the same as the term MLA defined in 
draft-ietf-autoconf-statement-02.txt ?
Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 19 Nov 2007 14:54:49 +0100

Hi Emmanuel,

Here a suggested text:

   MANET Global Address (MGA)  - An IP address configured on a MANET
      interface, and valid for communications inside the MANET and for
      communications with corresponding nodes on the Internet, via a
      Border Router. A MGA is associated with a Border Router, for being 
      topologically correct.

Global Address is to be replaced. With MGA.

Please verify definition for Global prefix. There are conditions that IP
addresses are invalid for communications reaching outside the MANET. And why
is it reserved for MANET Routers? Why not using a range? (RFC3633 uses
prefixes, that could be a reason).

I do not like the term "Internet Configuration Provider (ICP)". Why not
using DHCP Server? Or is it something else? Must this be a Router? Why? Why
can't it provide prefixes or addresses to hosts? Large infrastructures
typically have separated routers and address assignment servers. I reject
text defining that these are integrated in one device. It may be, but _not_
should be and _certainly not_ must be.

On DHCP-PD, I reread the problem statement document. When all nodes perform
DHCP functions, as 3633 RR and DR, what are the problems? I don't think this
scenario is optimal, but it should work. 
Problems could be:
 - BR ingress filter, relation with routing
 - Session continuity problem when path via BR is not available anymore
 - Running DHCP on some platforms
 - Inefficient address usage

Cheers, Teco.

> Verzonden: maandag 19 november 2007 14:01
> Aan: [email-masked]
> >> Here, in this case, I think it is important to describe the
> scenarios
> >> in
> >> I think you may be right to deduce that the problems are similar,
> but
> >> to

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 20 Nov 2007 15:09:56 +0100

Hi Teco,

> prefixes, that could be a reason).

OK, I see what you mean. I think that we do not need to create new terms 
other than global prefix and global address. We just need to make sure 
that people understand what these terms mean in the context of MANETs.

> should be and _certainly not_ must be.

OK. So maybe we could talk about an "entity" instead of a "router"? This 
would be more general I agree.

>  - Inefficient address usage

Yes, especially you'd get into trouble if no server is reachable and the 
MANET is not "full mesh". This is the case of most standalone MANETs, 
for instance.

Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 20 Nov 2007 16:02:50 +0100

> Verzonden: dinsdag 20 november 2007 15:10
> Aan: [email-masked]

Do you agree on the definition for MGA, being used for GA?

> would be more general I agree.

First, I want to know why we can't use the term DHCP server. I really can't
follow why we are not considering DHCP-PD. 

> MANET is not "full mesh". This is the case of most standalone MANETs,

I think DHCP can perfectly being used, as long as it is reachable.
If no DHCP is reachable, I assume the MANET is standalone, OK? So there is
no need for GA.
When there is a DHCP reachable (single hop, using link local or MLA), it can
provide an MLA. Using such an MLA can be more efficient for transport over
PacketBB related to random MLA (see different thread for details).
I think MLA can be relatively static, e.g. using long DHCP lease times.
Reachability to DHCP server is needed every now and then.

The question is, can this DHCP provided address also be used as GA? So now
we are back to the problem that GA is associated with a BR. Here, we have
the relation between GA and BR. 

In MIP & NEMO, we use the term Mobile Network Prefix (MNP) and Home Address
(HoA) for a similar topic, these are globally unique (guaranteed by some
mechanism), and they are associated with a HA.
I'll keep using MGA for GA associated with BR. The problem is almost
equivalent.

Keep in mind that the real stuff runs all these protocols, not MIP or NEMO
or MANET. So there are MNP, HoA, multiple CoA (each associated with a tunnel
to HA), MLA and multiple MGA (each associated with a xxxx to BR). Don't say
this is not confusing. And I do not agree in using GA for all of those!!!!!

Teco.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 20 Nov 2007 18:39:12 +0100

Hi Teco,

> Do you agree on the definition for MGA, being used for GA?

Yes. I think it is good. I am working as we speak on -03. The definition 
for global address will be this one.

> follow why we are not considering DHCP-PD. 

DHCP is a solution. We are not talking a solution in particular. We are 
talking about a fundamental problem, so the vocabulary has to be 
generic, and precise at the same time. An ICP can be a DHCP server, no 
problem. Soo you agree with the following definition?

Internet Configuration Provider (ICP)  - An entity that can provide
       routers requesting configuration with addresses or prefixes
       derived from a global prefix.

> Reachability to DHCP server is needed every now and then.

I agree that DHCP is a strong candidate for part of the solution to the 
connected MANET case. But it is only a candidate, and it does not solve 
everything. Do you agree on this?

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 20 Nov 2007 19:39:55 +0100

Hi Emmanuel, Inline.

> Verzonden: dinsdag 20 november 2007 18:39
> Aan: [email-masked]
> >>> Please verify definition for Global prefix. There are conditions
> that
> >> IP
> >>> addresses are invalid for communications reaching outside the
> MANET.
> >> And why

Only the M prepended ;-)

> >>> text defining that these are integrated in one device. It may be,
> but
> >> _not_

Yes and no.
We have lots of fundamental problems. Let's discuss the length of an IPv8
address;-)
If you want to use a generic term for a DHCP server, or AAA server providing
addresses, OK.
But would use this term a lot, as problems cannot be defined, as we do not
know what it is.
For example, using AAA has very different problems than DHCP.

I prefer being very accurate when describing problems. It helps the
discussions.

On the definition, please change routers into nodes.
And find other text for the reply. If a node request configuration, the
reply is configuration and not limited to addresses or prefixes. Or use
Address and Prefix Providing Entity. Both AAA and DHCP provides more than
that. And for very good reasons.

> everything. Do you agree on this?

Yes, please add this in the PS document, that DHCP is indeed a candidate.
And when there is no problem, we could use it starting today and we can stop
Autoconf.
I expect problems, our job is writing them down first and then solve, after
selecting one out of the candidates.
I think this is our job.

Maybe add AAA, e.g. radius? I expect some problems, but it has good aspects
also. I think ISP prefer secured access and AAA is invented for it.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 20:17:57 +0100

Emmanuel Baccelli wrote:
> Hi Teco,
> 
> Teco Boot a écrit :
>>> -----Oorspronkelijk bericht----- Van: Emmanuel Baccelli 
>>> [mailto:[email-masked]] Verzonden: dinsdag 20 
>>> november 2007 15:10 Aan: [email-masked] Onderwerp: Re: 
>>> [Autoconf] Re: Scenarios and Requirements
>>> 
>>> Hi Teco,
>>> 
>>> Teco Boot a écrit :
>>>> MANET Global Address (MGA)  - An IP address configured on a 
>>>> MANET interface, and valid for communications inside the MANET
>>>>  and
>>> for
>>>> Please verify definition for Global prefix. There are 
>>>> conditions that
>>> IP
>>>> is it reserved for MANET Routers? Why not using a range? 
>>>> (RFC3633
>>> uses
>>> OK, I see what you mean. I think that we do not need to create 
>>> new terms other than global prefix and global address. We just 
>>> need to make sure that people understand what these terms mean in
>>>  the context of MANETs.
>> 
> Yes. I think it is good. I am working as we speak on -03. The 
> definition for global address will be this one.
> 
>>>> I do not like the term "Internet Configuration Provider (ICP)".
>>>>  Why
>>> not
>>>> using DHCP Server? Or is it something else? Must this be a 
>>>> Router?
>>> Why? Why
>>>> typically have separated routers and address assignment 
>>>> servers. I
>>> reject
>>>> text defining that these are integrated in one device. It may 
>>>> be, but
>>> _not_
>>> OK. So maybe we could talk about an "entity" instead of a 
>>> "router"? This would be more general I agree.
>> 
>> First, I want to know why we can't use the term DHCP server. I 
>> really can't follow why we are not considering DHCP-PD.
> 
> DHCP is a solution. We are not talking a solution in particular. We 
> are talking about a fundamental problem, so the vocabulary has to be
>  generic, and precise at the same time.

Sorry, I don't see any fundamental problems.

I don't think we can solve any problem by stating from the start it's
'fundamental'.

I will not work on any fundamental problem.

> An ICP can be a DHCP server, no problem. Soo you agree with the 
> following definition?
> 
> from a global prefix.

I'd agree if you added "typically a DHCP Server".

>>>> On DHCP-PD, I reread the problem statement document. When all 
>>>> nodes
>>> perform
>>>> DHCP functions, as 3633 RR and DR, what are the problems? I 
>>>> don't
>>> think this
>>>> scenario is optimal, but it should work. Problems could be: - 
>>>> BR ingress filter, relation with routing - Session continuity 
>>>> problem when path via BR is not available
>>> anymore
>>>> - Running DHCP on some platforms - Inefficient address usage
>>> Yes, especially you'd get into trouble if no server is reachable
>>>  and the MANET is not "full mesh". This is the case of most 
>>> standalone MANETs, for instance.
>> 
>> If no DHCP is reachable, I assume the MANET is standalone, OK? So 
>> there is no need for GA. When there is a DHCP reachable (single 
>> hop, using link local or MLA), it can provide an MLA. Using such an
>>  MLA can be more efficient for transport over PacketBB related to 
>> random MLA (see different thread for details). I think MLA can be 
>> relatively static, e.g. using long DHCP lease times. Reachability 
>> to DHCP server is needed every now and then.
>> 
> 
> I agree that DHCP is a strong candidate for part of the solution to 
> the connected MANET case. But it is only a candidate, and it does not
>  solve everything. Do you agree on this?

It is a good candidate.  It may solve many scenarios.  I haven't seen a
scenario where it wouldn't work, and where stateless autoconf wouldn't
work, but I'm interested to learn it.

Alex

---

From: "Simone Ruffino" <[email-masked]>
Date: Wed, 21 Nov 2007 10:07:43 +0100

Hi all,
see inline.
Simone

Teco Boot wrote:
>> MANET
>>>>>       interface, and valid for communications inside the MANET and
>>>>>           
>>>> for
>>>>         
>>>>>       communications with corresponding nodes on the Internet, via
>>>>>           
>> a
>>     
>>>>>       Border Router. A MGA is associated with a Border Router, for
>>>>>           
>>>> being
>>>>         
>>>>>       topologically correct.
>>>>>
>>>>>
>>>>> is it reserved for MANET Routers? Why not using a range? (RFC3633
>>>>>           
>>>> uses
>>>>         
>>>> other than global prefix and global address. We just need to make
>>>>         
>> sure
>>     
>>>> that people understand what these terms mean in the context of
>>>>         
>> MANETs.
>>     

I also like Teco's text, but I don't understand yet, why we need to 
define MGA. Aren't we actually re-defining standard, well-known, 
well-established IPv6 GA? Are MGA different from IPv6 GA to any extent? 
Do we really need to have a new acronym here?
I raise again this issue, because, in my opinion, this particular 
definition can generate more confusion.
Suggestion : so not have a definition for MGA or GA at all.

>   
>>>>> I do not like the term "Internet Configuration Provider (ICP)". Why
>>>>>           
>>>> not
>>>>         
>>>>> using DHCP Server? Or is it something else? Must this be a Router?
>>>>>           
>>>> Why? Why
>>>>         
>>>>> can't it provide prefixes or addresses to hosts? Large
>>>>>           
>>>> infrastructures
>>>>         
>>>>> typically have separated routers and address assignment servers. I
>>>>>           
>>>> reject
>>>>         
>>> First, I want to know why we can't use the term DHCP server. I really
>>>       
>> can't
>>     

Emmanuel, I also think that ICP is not clear. If it is an entity 
external to MANETs, we should really write that it can be a DHCP 
servero, or a AAA server.

 If your goal is using it to define "connected" vs. "disconnected" 
MANET, I think that it is not appropriate: to me, the difference is that 
a "connected" MANET has *at least* one MANET border router that routes 
packet towards/from an external network, s.a. the Internet.

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 21 Nov 2007 10:15:10 +0100

Alexandru Petrescu a écrit :
>>> can't follow why we are not considering DHCP-PD.
>>

I see. I guess we are still at this point were it is not understood that 
there is a problem regarding semi-broadcast...

> I'd agree if you added "typically a DHCP Server".

OK, this is possible. In -03 i will add "for example a DHCP Server".

>>>>> scenario is optimal, but it should work. Problems could be: - BR 
>>>>> ingress filter, relation with routing - Session continuity problem 
>>>>> when path via BR is not available
>>>> anymore
>>> I think DHCP can perfectly being used, as long as it is reachable. If 
>>> no DHCP is reachable, I assume the MANET is standalone, OK? So there 
>>> is no need for GA. When there is a DHCP reachable (single hop, using 
>>> link local or MLA), it can provide an MLA. Using such an
>>> relatively static, e.g. using long DHCP lease times. Reachability to 
>>> DHCP server is needed every now and then.
>>>
>>

Are you saying that there is no issues using DHCP and ND with
- dynamic topology
- semi-broadcast behavior
- network merging/partitionning
Are you saying that?

Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Nov 2007 12:28:19 +0100

Emmanuel Baccelli wrote:
>>> DHCP is a solution. We are not talking a solution in particular.
>>> We are talking about a fundamental problem, so the vocabulary has
>>> to be generic, and precise at the same time.
>> 
>> I don't think we can solve any problem by stating from the start
>> it's 'fundamental'.
>> 
> I see. I guess we are still at this point were it is not understood
> that there is a problem regarding semi-broadcast...

I had a private exchange with Teco recently.  We were looking on mail
(not real life) at a wifi scenario placed linearly A-C-B with 50m in
between.  Supposedly A is too far from B to hear it, range being 50m.
And then see how to make it work with IPv6.

There are several possibilities: a single adhoc essid and a single
subnet.  Two adhoc essids (A-C and C-B) and a single subnet.  C could
have one or two interfaces.  A single ap-mode essid managed by C as
access point.  A single subnet or two different subnets (A-C and C-B).

Which of these configurations do you think would work?  I personally
think two subnets and C with two interfaces will surely work; and C as
AP and a single  subnet will also work.   For others combinations I have
some doubts.

(in these we're considering laptops/pdas/phones with pcmcia or centrino
  cards, no external antenna - a dedicated 10dbi wifi antenna can extend
the range into kilometersbecause a wifi Yagi antenna  was reported
  to hear as far as to 9km, way out of our testing possibilities).

>>> Internet Configuration Provider (ICP)  - An entity that can
>>> provide routers requesting configuration with addresses or
>>> prefixes derived from a global prefix.
>> 

Thanks.

More DHCP text in the draft that I don't agree with:
> located on the same logical link.  While DHCP can to some extent
> overcome this issue in a static network, it is not the case in a
> dynamic topology, as explained below. [Figure 1 and explanation
> following]

I think even in a dynamic topology DHCP works.  In the figure you
pictured there's an entity missing in the picture.  It's a MR that you
replaced with 3 dots.  It's MR4, the last hop router towards the MR3 on
which you want to allocate a prefix.  That router is the DHCP Relay.
Imagine that topology is fixed one moment.  DHCP works ok for MR3.  Then
topology starts to move, MR4 moves away and MR5 takes its place.
Nothing else moved.  Now MR4 will re-start DHCP (basically send Solicit
again), MR5 will relay it to the server and so on.  Of course, MR5 must
be pre-configured as a Relay with the DHCP Server's address.

In this movement scenarion DHCP works ok.

What is the movement scenario where you think DHCP doesn't work?

>>>>>> On DHCP-PD, I reread the problem statement document. When
>>>>>> all nodes
>>>>> perform
>>>>>> scenario is optimal, but it should work. Problems could be:
>>>>>> - BR ingress filter, relation with routing - Session
>>>>>> continuity problem when path via BR is not available
>>>>> anymore
>>>>> Yes, especially you'd get into trouble if no server is
>>>>> reachable and the MANET is not "full mesh". This is the case
>>>>> of most standalone MANETs, for instance.
>>>> 
>>>> I think DHCP can perfectly being used, as long as it is
>>>> reachable. If no DHCP is reachable, I assume the MANET is
>>>> standalone, OK? So there is no need for GA. When there is a
>>>> DHCP reachable (single hop, using link local or MLA), it can
>>>> provide an MLA. Using such an MLA can be more efficient for
>>>> transport over PacketBB related to random MLA (see different
>>>> thread for details). I think MLA can be relatively static, e.g.
>>>> using long DHCP lease times. Reachability to DHCP server is
>>>> needed every now and then.
>>>> 
>>> 
>>> I agree that DHCP is a strong candidate for part of the solution
>>> to the connected MANET case. But it is only a candidate, and it
>>> does not solve everything. Do you agree on this?
>> 
>> It is a good candidate.  It may solve many scenarios.  I haven't
>> seen a scenario where it wouldn't work, and where stateless
>> autoconf wouldn't work, but I'm interested to learn it.
>> 
> 
> Are you saying that there is no issues using DHCP and ND with -
> dynamic topology - semi-broadcast behavior - network
> merging/partitionning

(I think there are some issues with DHCP Prefix Delegation and DHCP
  Relay relating to routing..)

The issues of DHCP and ND have nothing to do with eg dynamic topology as
long as we don't say precisely what _is_ dynamic topology, how things
move at IP layer and what are the ranges and control points.

Semi-broadcast behaviour is a MANET term, experimented with WiFi links.
  I'm wondering whether 'semi-broadcast' appears in 802.11 specs, and to
which wifi term would it correspond.  Could someone explain what "[SBI]
exhibits time-varying asymmetric reachability and spatially distributed
MANET routers" means in terms of 802.11 standards and implementations?
Or in terms of ND and ARP and DHCP?  From that we can discuss.

Network merging/partitioning are terms that appear to be specific to
MANET networks.  At the same time they look very simmilar to how
networks are automatically built (NAT, DHCP, ND, stateless, link-local
addresses)with various PDA devices.  However no relationship is made
between the two, that's why I don't understand what is meant.

Alex