Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt

"Ray Hunter (v6ops)" <v6ops@globis.net> Thu, 26 November 2015 14:08 UTC

Return-Path: <v6ops@globis.net>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8F01B3A03 for <homenet@ietfa.amsl.com>; Thu, 26 Nov 2015 06:08:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPovYTBDmeEA for <homenet@ietfa.amsl.com>; Thu, 26 Nov 2015 06:08:41 -0800 (PST)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF1A1B3A04 for <homenet@ietf.org>; Thu, 26 Nov 2015 06:08:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D63C94034B; Thu, 26 Nov 2015 15:08:39 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJpKNkTr4K7y; Thu, 26 Nov 2015 15:08:33 +0100 (CET)
Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 94B8C40348; Thu, 26 Nov 2015 15:08:33 +0100 (CET)
Message-ID: <56571260.6040504@globis.net>
Date: Thu, 26 Nov 2015 15:08:32 +0100
From: "Ray Hunter (v6ops)" <v6ops@globis.net>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: homenet@ietf.org
References: <20151016113242.29159.37112.idtracker@ietfa.amsl.com> <5620E158.4000309@openwrt.org> <56265237.8020202@gmail.com>
In-Reply-To: <56265237.8020202@gmail.com>
Content-Type: multipart/alternative; boundary="------------000108040700020002010200"
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/fmaCXX0dyv4wVdGNz8m3nzuu1kM>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Subject: Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2015 14:08:43 -0000


Alexandre Petrescu wrote:
> Hi,
>
> Using host-based routes in a homenet to support mobility (rather than 
> Mobile IP) may make sense because the domain is relatively small.
>
> The draft could benefit from illustrating at least a simple topology, 
> to understand what the author really means, because there are very 
> many possible topologies to talk about.
>
> Alex
>
> Le 16/10/2015 13:36, Steven Barth a écrit :
>> Hi everyone,
>>
>> here is some attempt to formalize a simple WiFi roaming approach
>> using host routes and a stateless proxy for DAD NDP messages.
>>
>> It's a bit theoretical right now but may be useful as a start for a
>> discussion. We could do a talk on it in Yokohama as well.
>>
>>
>>
>> Cheers,
>>
>> Steven
>>
>>
>> On 16.10.2015 13:32, internet-drafts@ietf.org wrote:
>>> A new version of I-D, draft-barth-homenet-wifi-roaming-00.txt
>>> has been successfully submitted by Steven Barth and posted to the
>>> IETF repository.
>>>
>>> Name:        draft-barth-homenet-wifi-roaming
>>> Revision:    00
>>> Title:        Home Network WiFi Roaming
>>> Document date:    2015-10-16
>>> Group:        Individual Submission
>>> Pages:        7
>>> URL:            
>>> https://www.ietf.org/internet-drafts/draft-barth-homenet-wifi-roaming-00.txt 
>>>
>>> Status:         
>>> https://datatracker.ietf.org/doc/draft-barth-homenet-wifi-roaming/
>>> Htmlized:       
>>> https://tools.ietf.org/html/draft-barth-homenet-wifi-roaming-00
>>>
>>>
>>> Abstract:
>>>     This document describes a mechanism to manage host routes and
>>>     statelessly proxy IPv6 Duplicate Address Detection messages between
>>>     multiple WiFi links to allow client roaming.
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of 
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>
>

I have read this draft and find it interesting.

The use of host routes would seem appealing to avoid
1) any need for stateful "home agent" and multiple forwarding
2) renumbering of the end nodes when roaming
3) relatively small number of hosts compared to the complexity of the 
topology

Use of RFC7217 addresses would seem appropriate, but that assumes that 
DAD really is reliable at the time a node attaches to the homenet for 
the first time.

What happens if a homenet becomes temporarily "split-brain" and then 
remerges?
Isn't there a danger of two nodes acquiring the same address.
What happens then? (as DAD has already completed on both client nodes)

What's the mechanism/timing of ND expiry compared to WIFI roaming and 
distribution of route updates?
Isn't this going to be "too slow"?
Should the routers be performing an active "keep alive" on locally 
attached nodes?
[not good for battery life on wireless]

What about using an explicit registration, with each homenet router 
acting as a 6LBR?
e.g. RFC6775 ND Optimization for 6LoWPANs, as the registration 
mechanism, which is then used to inject the host route.

What's the benefit/downside of this approach compared to having roaming 
nodes actively take part in the HNCP acting as "multi-homed routers" 
with an internal (invariant) /64 VLAN used to bind to applications?

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>