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

"Ray Hunter (v6ops)" <> Mon, 30 November 2015 10:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B70561A8AEA for <>; Mon, 30 Nov 2015 02:41:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 4.981
X-Spam-Level: ****
X-Spam-Status: No, score=4.981 tagged_above=-999 required=5 tests=[FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cT7w6XDdaTh2 for <>; Mon, 30 Nov 2015 02:41:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 630721A8AED for <>; Mon, 30 Nov 2015 02:41:19 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB3384034A; Mon, 30 Nov 2015 11:41:16 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hBibZ6T7C1CK; Mon, 30 Nov 2015 11:41:13 +0100 (CET)
Received: from Rays-MacBook-Pro.local ( []) (Authenticated sender: by (Postfix) with ESMTPA id D638340348; Mon, 30 Nov 2015 11:39:12 +0100 (CET)
Message-ID: <>
Date: Mon, 30 Nov 2015 11:38:36 +0100
From: "Ray Hunter (v6ops)" <>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Mikael Abrahamsson <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------000205020200050606050109"
Archived-At: <>
Subject: Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Nov 2015 10:41:20 -0000

> Mikael Abrahamsson <>
> 30 Nov 2015 08:33
> On Fri, 27 Nov 2015, Ray Hunter (v6ops) wrote:
>> How would you "move a /64 around"?
> Well, the same way you would move a /128 around I guess.
Not sure that's correct.

When moving a /64 per host you have to presume a /64 has been allocated 
to a host already.

So every time a new host joined wifi you'd have to re-run the entire 
HNCP prefix allocation algorithm AFAICS, and check whether there's a 
conflict of this /64 still being active elsewhere. Unless of course you 
pre-allocate a pool in advance assuming there'll be a certain number of 
hosts on wifi.

On the other hand, for moving individual hosts, I've used a CIDR trick 
in the past when moving data centres that 2 or more LANs are configured 
with an identical IPv4 prefix, and then I've added host routes + proxy 
ARP to trick hosts into thinking they're actually directly connected. 
Should also work for IPv6 as long as CIDR is truly 128 bits (RFC7608).

So it seems to me the missing pieces of the puzzle could be:

1. Identifying cooperating router interfaces across the Homenet and 
assigning a common /64 to them in prefix allocation
2. Maintaining a list of /128 wifi hosts bound to the cooperating 
routers interfaces [including MAC address].
3. detecting "side changes" (in bridge speak) where a host has changed 
connection point and packets are arriving on a new cooperating 
interface. Could potentially be detected when receiving a DAD for a /128 
from the list of wifi hosts with identical MAC address to one previously 
4. injecting and removing /128 routes as hosts move between cooperating 
interfaces, and updating with list of /128 wifi hosts.
5. Proxy ND equivalent to proxy ARP to answer ND requests on cooperating 
router "local" interfaces for hosts connected to "remote" interfaces.

Proxy ND would include DAD [defending a request for a /128 on a 
cooperating interface with a MAC address not included in the list of 
/128 wifi hosts], but also answering standard ND queries AFAICS so that 
wi-fi connected hosts could inter-communicate. Answers to standard 
queries could be triggered by the presence of a /128 route in a similar 
way to IPv4 proxy-arp.

>> I'm presume cooperating routers would have to maintain a translation 
>> table of MAC address to /64 prefix per host wireless interface.
>> What's the practical difference with moving a /64 (which still 
>> requires routing changes AFAICS) compared to moving a /128 host route?
> None, apart from that a host seldom has a single /128 but instead 
> several /128:s. The biggest upside is that you don't need to do DAD 
> handling between participating wifi routers (since the host is alone 
> in the /64, there is no need to do inter-router DAD).