Re: [Autoconf] draft-boot-autoconf-support4hosts

Teco Boot <teco@inf-net.nl> Mon, 06 December 2010 21:49 UTC

Return-Path: <teco@inf-net.nl>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7C83A68BE for <autoconf@core3.amsl.com>; Mon, 6 Dec 2010 13:49:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.416
X-Spam-Level:
X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cK4ASegwFJh for <autoconf@core3.amsl.com>; Mon, 6 Dec 2010 13:49:06 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 9136D3A68C5 for <autoconf@ietf.org>; Mon, 6 Dec 2010 13:49:06 -0800 (PST)
Received: by wwa36 with SMTP id 36so13141663wwa.13 for <autoconf@ietf.org>; Mon, 06 Dec 2010 13:50:30 -0800 (PST)
Received: by 10.216.235.211 with SMTP id u61mr5323101weq.91.1291672230063; Mon, 06 Dec 2010 13:50:30 -0800 (PST)
Received: from [192.168.2.166] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id p4sm2601656wej.4.2010.12.06.13.50.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 13:50:28 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <4CF986C5.8070208@earthlink.net>
Date: Mon, 6 Dec 2010 22:50:25 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <C55AFC27-A79F-47ED-8FBE-F9D402EF56CF@inf-net.nl>
References: <20101129212013.184B53A6BDB@core3.amsl.com> <E0D3D031-3334-40A2-BAE1-D1E045DBB798@inf-net.nl> <4CF986C5.8070208@earthlink.net>
To: Charles E. Perkins <charles.perkins@earthlink.net>
X-Mailer: Apple Mail (2.1081)
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] draft-boot-autoconf-support4hosts
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Dec 2010 21:49:08 -0000

Hello Charlie,

Thanks for reviewing.
I posted a -01. I hope it clears up a bit.
http://www.ietf.org/id/draft-boot-autoconf-support4hosts-01.txt

Op 4 dec 2010, om 01:09 heeft Charles E. Perkins het volgende geschreven:

> 
>>                    Packet forwarding between hosts is always lead
>>   via one ore more MANET routers, unless link-local addresses are used
>>   and direct reachability between the hosts exists.
> 
> I did not understand this sentence.

Now, diagrams and text is added.
It shows when LLs work, and when it fails.
Maybe MPTCP can support LLs and find out automatically 
if a host-host path exists and has larger throughput 
as a path via router(s).


>>                                                  However, usage of
>>   link-local addresses is not recommended, as non-link-local addresses
>>   provide better support for session continuity in mobile environments.
> 
> I was surprised to read that the purpose for using non-link-local
> addresses was for session continuity.  I think it is more along the
> lines of "identity preservation and uniqueness".

I guess mobility solutions are not designed for link-locals.
But this is not clear in this sentence, so I reworded.


>> Charles E. Parkins
> 
> Thanks for the acknowledgement.  My last name has
> an 'e' in it :-).

Who said it was you? :-)


>>                                                Mobility
>>   solutions are already available and can be used in the MANET
>>   scenario.
> 
> This is true, but usually is considered in the context
> of having a home agent in the Internet instead of in
> the ad-hoc network.  Is this what you are proposing?

There are mobility solutions that don't need a home agent. E.g. I
suggested running a MANET routing protocol.

I am aware of MANETs where main requirement is connectivity with 
nodes on the Internet. Here, MIP6 could work quite well.

Another model is using the router that provided the 1st configured prefix
as MIP6 HA. When Host1 gets address from RtrA and assigns address HostA,
it could use this address as home address. When later on, an address
HostB with prefix from RtrB is assigned, it could bind this HostB address
as care-of address to HA RtrA. Route optimization can be performed with
for example MPTCP.
Legacy hosts would not perform such functions, but I think it is doable.


Regards, Teco