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: [email protected]
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
