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

[Mikael Abrahamsson <[e-mail]>]

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: [e-mail]