[Autoconf] Fwd: Some Thoughts on Problem Statement.

Shubhranshu <shubranshu@gmail.com> Fri, 23 November 2007 17:17 UTC

Return-path: <autoconf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivc9j-0003G0-6l; Fri, 23 Nov 2007 12:17:31 -0500
Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Ivc9g-0003Fq-Dq for autoconf-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 12:17:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivc9g-0003Fd-4E for autoconf@ietf.org; Fri, 23 Nov 2007 12:17:28 -0500
Received: from an-out-0708.google.com ([209.85.132.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivc9d-0007Oy-KG for autoconf@ietf.org; Fri, 23 Nov 2007 12:17:28 -0500
Received: by an-out-0708.google.com with SMTP id d11so726461and for <autoconf@ietf.org>; Fri, 23 Nov 2007 09:17:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=r5mwDnB/8GJsncE6nTZExycXX4c94P2nVwbvie4f51s=; b=XoYQf/40iIs8so9s+9QPFebCsxGMM/K8qgZVNbPtQuadXoZ3vZN6Q7cvOhb/hBu4a7v9mPF0Z/w2YHaO/xSbL/oVaSjVZ+ium2EfOJE5736b2KBw/ox7E7NNqhISY7ICDH4SSSYxD8YK71eVUtd/0T3lJVtFGIDefM4dQvfhGUk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lbyvZIqHMgDIbzGiXE5IldVqPjCPt6rQZLsLn2Z/L+kv9+VFqeUTL+UlCYJxmRxVw7JoIqdLhFppWFyFVm8W42cN75dj4Wl9kT+o6+HFbWyQ3cwNF1qRk0tpX584YkoWUtIMduvALp2lZwclTj4FmjMexocpHBrV2OYGPZycLvA=
Received: by 10.100.208.11 with SMTP id f11mr14404243ang.1195838245343; Fri, 23 Nov 2007 09:17:25 -0800 (PST)
Received: by 10.100.229.8 with HTTP; Fri, 23 Nov 2007 09:17:25 -0800 (PST)
Message-ID: <e9c684940711230917h6e1615e6v4f9e458dfa339798@mail.gmail.com>
Date: Sat, 24 Nov 2007 02:17:25 +0900
From: Shubhranshu <shubranshu@gmail.com>
To: autoconf@ietf.org
In-Reply-To: <e9c684940711230826p323a818fg114da3c710841f2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e9c684940711230826p323a818fg114da3c710841f2@mail.gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Subject: [Autoconf] Fwd: Some Thoughts on Problem Statement.
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
Errors-To: autoconf-bounces@ietf.org

A correction, please see below

---------- Forwarded message ----------
From: Shubhranshu <shubranshu@gmail.com>
Date: Nov 24, 2007 1:26 AM
Subject: Some Thoughts on Problem Statement.
To: autoconf@ietf.org

<snip>

- Scenario where no DHCP server is available.

By its very nature, MANET environment does not always assume
availability of any pre-configured server. Even in such scenarios a
MANET router needs to configure an unique prefix. Traditionally,
protocols such as RFC 2462 are used for address configuration of nodes
in stateless manner. However,  RFC 2462 defines address auto
configuration mechanisms for nodes (host and router) and as such it

>>  "2462 defines address auto configuration mechanisms for nodes
(hosts and not routers)".

- Shubhranshu

does not provide any mechanism for allocating "unique prefix(es)" to
the routers. For example, in Figure 2 below, a MANET Router, say MR3,
may need to receive prefix(es) (which can be further subnetted and
used for address configuration of its attached host nodes) from the
MANET Boarder Router /Access Router. Currently no specification exists
that addresses this requirement.

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

Fig 2. (same as Fig 2 in draft-ietf-autoconf-statement-02)


Mobile and wireless nature of MANET routers result in dynamic network
topology [MANET-Arch ID, RFC 2501] which has the property of changing
neighbor nodes. These MANET properties result in network partitioning
and merger of initially isolated networks. Normally, once an address
is allocated to a node, it continues using it and collaborating to
detect and resolve duplicates in case its address is allocated to any
other node. Since initially isolated MANETs had allocated  addresses
independent with each other, there remains probability of more than
one node using same address. Currently there is no specification that
solves problem of MANET "network merger detection" and duplicate
address detection/ resolution resulting due to two / more MANETs
merger.

It is desirable that network partitioning is also detected such that
resources / prefixes that were allocated to the outgoing nodes could
be re-used. Currently there is no specification to solve the problem
of MANET  "network merger detection".


_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf