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

Mikael Abrahamsson <> Mon, 30 November 2015 11:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 10AFA1A90A8 for <>; Mon, 30 Nov 2015 03:04:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.239
X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qUkU02cEyZJJ for <>; Mon, 30 Nov 2015 03:04:03 -0800 (PST)
Received: from ( [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 658CA1A90A7 for <>; Mon, 30 Nov 2015 03:04:03 -0800 (PST)
Received: by (Postfix, from userid 501) id 0FF62A2; Mon, 30 Nov 2015 12:04:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1448881441; bh=bmtgvmL7thKZ2ejkFsaUqPhEZElrvpR8pWtPe4f+pTk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lacTjZGnOolwh91xoQTHZbl/Qt6z9EB1ljDcAHO72CUPcWCl1P++sTAtKQZM3+yzC 5v46IlhG9vOXlhmBLXExgtVLooIfHi6SCvSSQCPApUpj/sk0Suj9MtH0U2i7wl0WCu CyotyvFKJJQCLGAeiqf/V2LeATRYmRefeeXleJmQ=
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06C62A1; Mon, 30 Nov 2015 12:04:01 +0100 (CET)
Date: Mon, 30 Nov 2015 12:04:00 +0100 (CET)
From: Mikael Abrahamsson <>
To: "Ray Hunter (v6ops)" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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 11:04:05 -0000

On Mon, 30 Nov 2015, Ray Hunter (v6ops) wrote:

> Not sure that's correct.
> When moving a /64 per host you have to presume a /64 has been allocated to a 
> host already.

Wouldn't all HNCP speakers need to know all /128 <-> MAC mappings anyway? 
So they'd have to know the same /64 <-> MAC mappings. I don't understand 
the fundamental difference.

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

No, but when an HNCP speaking wifi-handling device allocates a /64 or 
detects a /128 being in use by a device, wouldn't that information have to 
be shared network-wide anyway?

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

Yes, I have done the same, but in order to speed up handovers, wouldn't 
you want ND tables to be pre-populated in the /128 case anyway, ie ND 
information needs to be shared between all HNCP speakers?

So what I see /64 saving is that instead of keeping state for /128 (where 
a host might have a lot of them), you just keep state for a single /64 <-> 
MAC mapping (still network wide).

Mikael Abrahamsson    email: