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

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 30 November 2015 11:04 UTC

Return-Path: <swmike@swm.pp.se>
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 10AFA1A90A8 for <homenet@ietfa.amsl.com>; Mon, 30 Nov 2015 03:04:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.239
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUkU02cEyZJJ for <homenet@ietfa.amsl.com>; Mon, 30 Nov 2015 03:04:03 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658CA1A90A7 for <homenet@ietf.org>; Mon, 30 Nov 2015 03:04:03 -0800 (PST)
Received: by uplift.swm.pp.se (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; d=swm.pp.se; 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 [127.0.0.1]) by uplift.swm.pp.se (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 <swmike@swm.pp.se>
To: "Ray Hunter (v6ops)" <v6ops@globis.net>
In-Reply-To: <565C272C.7040000@globis.net>
Message-ID: <alpine.DEB.2.02.1511301154360.24520@uplift.swm.pp.se>
References: <20151016113242.29159.37112.idtracker@ietfa.amsl.com> <5620E158.4000309@openwrt.org> <56265237.8020202@gmail.com> <56571260.6040504@globis.net> <alpine.DEB.2.02.1511261610310.24520@uplift.swm.pp.se> <5658D282.1040006@globis.net> <alpine.DEB.2.02.1511300831000.24520@uplift.swm.pp.se> <565C272C.7040000@globis.net>
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: <http://mailarchive.ietf.org/arch/msg/homenet/3BOF9DRc-6hfnkZ4Bxp7RnK4Wa8>
Cc: homenet@ietf.org
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: 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: swmike@swm.pp.se