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

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Thu, 26 Nov 2015 15:08:32 +0100

Alexandre Petrescu wrote:
> Hi,
>
> Using host-based routes in a homenet to support mobility (rather than 
> Mobile IP) may make sense because the domain is relatively small.
>
> The draft could benefit from illustrating at least a simple topology, 
> to understand what the author really means, because there are very 
> many possible topologies to talk about.
>
> Alex
>
> Le 16/10/2015 13:36, Steven Barth a écrit :
>> Hi everyone,
>>
>> here is some attempt to formalize a simple WiFi roaming approach
>> using host routes and a stateless proxy for DAD NDP messages.
>>
>> It's a bit theoretical right now but may be useful as a start for a
>> discussion. We could do a talk on it in Yokohama as well.
>>
>>
>>
>> Cheers,
>>
>> Steven
>>
>>
>> On 16.10.2015 13:32, [email-masked] wrote:
>>> A new version of I-D, draft-barth-homenet-wifi-roaming-00.txt
>>> has been successfully submitted by Steven Barth and posted to the
>>> IETF repository.
>>>
>>> Name:        draft-barth-homenet-wifi-roaming
>>> Revision:    00
>>> Title:        Home Network WiFi Roaming
>>> Document date:    2015-10-16
>>> Group:        Individual Submission
>>> Pages:        7
>>> URL:            
>>> https://www.ietf.org/internet-drafts/draft-barth-homenet-wifi-roaming-00.txt 
>>>
>>> Status:         
>>> https://datatracker.ietf.org/doc/draft-barth-homenet-wifi-roaming/
>>> Htmlized:       
>>> https://tools.ietf.org/html/draft-barth-homenet-wifi-roaming-00
>>>
>>>
>>> Abstract:
>>>     This document describes a mechanism to manage host routes and
>>>     statelessly proxy IPv6 Duplicate Address Detection messages between
>>>     multiple WiFi links to allow client roaming.
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of 
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>
>> _______________________________________________
>> homenet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>
>

I have read this draft and find it interesting.

The use of host routes would seem appealing to avoid
1) any need for stateful "home agent" and multiple forwarding
2) renumbering of the end nodes when roaming
3) relatively small number of hosts compared to the complexity of the 
topology

Use of RFC7217 addresses would seem appropriate, but that assumes that 
DAD really is reliable at the time a node attaches to the homenet for 
the first time.

What happens if a homenet becomes temporarily "split-brain" and then 
remerges?
Isn't there a danger of two nodes acquiring the same address.
What happens then? (as DAD has already completed on both client nodes)

What's the mechanism/timing of ND expiry compared to WIFI roaming and 
distribution of route updates?
Isn't this going to be "too slow"?
Should the routers be performing an active "keep alive" on locally 
attached nodes?
[not good for battery life on wireless]

What about using an explicit registration, with each homenet router 
acting as a 6LBR?
e.g. RFC6775 ND Optimization for 6LoWPANs, as the registration 
mechanism, which is then used to inject the host route.

What's the benefit/downside of this approach compared to having roaming 
nodes actively take part in the HNCP acting as "multi-homed routers" 
with an internal (invariant) /64 VLAN used to bind to applications?

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 26 Nov 2015 16:15:54 +0100 (CET)

On Thu, 26 Nov 2015, Ray Hunter (v6ops) wrote:

> Use of RFC7217 addresses would seem appropriate, but that assumes that DAD 
> really is reliable at the time a node attaches to the homenet for the first 
> time.

Wouldn't it be better to adopt 
https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-02 and 
just give every device its own /64 and move that around?

My worry about the whole L3 approach is how long does it take to 
re-establish packet flows after the L2 wifi handover between APs compared 
to an L2 only solution?

> with an internal (invariant) /64 VLAN used to bind to applications?

I'd say this approach adds one more layer that needs to come up before 
packets can start flowing again, especially since it would require routing 
protocol participation as well, I'd imagine.

If 802.11 can assure L2 handover in 1 second (I don't know how long the 
handover time is, just guessing), how much are we willing to add in time 
because of L3 mechanisms added on top of this, before packet flows are up 
and running again?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Nov 2015 07:28:57 -0800

On 11/26/2015 07:15 AM, Mikael Abrahamsson wrote:
>> Use of RFC7217 addresses would seem appropriate, but that assumes 
>> that DAD really is reliable at the time a node attaches to the 
>> homenet for the first time.
>
> https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-02 
> and just give every device its own /64 and move that around?
>
> re-establish packet flows after the L2 wifi handover between APs 
> compared to an L2 only solution?
>
>> What's the benefit/downside of this approach compared to having 
>> roaming nodes actively take part in the HNCP acting as "multi-homed 
>> routers" with an internal (invariant) /64 VLAN used to bind to 
>> applications?
>
> packets can start flowing again, especially since it would require 
> routing protocol participation as well, I'd imagine.
>
> If 802.11 can assure L2 handover in 1 second (I don't know how long 
> the handover time is, just guessing), how much are we willing to add 
> in time because of L3 mechanisms added on top of this, before packet 
> flows are up and running again?
>

Even if it's a 1/2 second, the l2 handover is still far too long for, 
say, real time flows. Isn't this why you want to
do make-before-break if at all possible? at that point, time-to-flow is 
less of an issue, right?

Mike

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Fri, 27 Nov 2015 23:00:34 +0100

> Mikael Abrahamsson <mailto:[email-masked]>
> 26 Nov 2015 16:15
Having a full /64 would seem attractive (for maintaining outbound 
sessions on temporary addresses etc.)

How would you "move a /64 around"?

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?

What's the practical difference in the trigger for executing the move 
(ND neighbor table update, as opposed to a MAC being detected as having 
changed attachment point)?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 30 Nov 2015 08:33:23 +0100 (CET)

> How would you "move a /64 around"?

Well, the same way you would move a /128 around I guess.

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

---

From: Dave Taht <[email-masked]>
Date: Mon, 30 Nov 2015 09:34:32 +0100

Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi

On Mon, Nov 30, 2015 at 8:33 AM, Mikael Abrahamsson <[email-masked]> wrote:
>> I'm presume cooperating routers would have to maintain a translation table
>> of MAC address to /64 prefix per host wireless interface.
>>
> /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).

I vote for moving /128s. This could even be a staged thing.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 30 Nov 2015 10:00:33 +0100 (CET)

> I vote for moving /128s. This could even be a staged thing.

Yes, it could be. I would be interested in numbers on the interruption 
time compared to an L2 solution when doing handovers. Also, how much 
complexity is needed for the whole DAD proxy thing? What do we do with 
IPv4, wouldn't it be easier to give each client a /28 or something, so we 
don't have to implement IPv4 proxy-arp and all that stuff as well?

It sounds to me that giving each client a subnet and not have to do the 
inter-AP DAD/proxy arp thing would greatly reduce complexity?

I have 3x WDR4900,2x WNDR3800 and 2x WRT1200AC to play with. If someone 
has code, I can do tests.

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Mon, 30 Nov 2015 11:38:36 +0100

> 30 Nov 2015 08:33
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 
observed.
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.

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 30 Nov 2015 12:04:00 +0100 (CET)

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

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Mon, 30 Nov 2015 13:03:05 +0100

Not sure that's correct.

So it seems to me the missing pieces of the puzzle for moving IPv6 /128 
could be:

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 30 Nov 2015 13:24:06 +0100 (CET)

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

No, you look in your table and see if the MAC address is known already to 
the HNCP domain, if known - hand out that /64, tell everybody else client 
has switche to you. If not, run HNCP /64 algo and tell everybody else.

You still have to sync all information between all HNCP speakers anyway in 
order to facilitate fast handover, both for /128 and /64 solution.

---

From: Steven Barth <[email-masked]>
Date: Mon, 30 Nov 2015 13:30:32 +0100

On 30.11.2015 13:24, Mikael Abrahamsson wrote:
> You still have to sync all information between all HNCP speakers anyway
> in order to facilitate fast handover, both for /128 and /64 solution.

That's not correct. If you read the draft, in the /128 case there is no
need for this information to be published using HNCP. You would only
publish which routers take part in the roaming.

Now, while I mostly agree that the /64 would make certain things easier,
it is not really a feasible solution unless we can ensure, that all ISPs
delegate _at least_ a /56.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 30 Nov 2015 13:34:49 +0100 (CET)

> publish which routers take part in the roaming.

Wouldn't it speed things up when doing handover, if the information was 
already known to all participating routers? It could populate ND tables 
immediately upon association instead of having to run ND queries itself?

---

From: Dave Taht <[email-masked]>
Date: Mon, 30 Nov 2015 13:39:05 +0100

> publish which routers take part in the roaming.

I generally speak as someone that has been deploying 128s for about 7?
years now.

However, my hosts participate in the roaming via babel. I realize that
a long held homenet mantra is "no hosts changes", but it isn't mine.
We can do a lot if we improve the endpoints.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 30 Nov 2015 14:08:39 +0100

* Steven Barth <[email-masked]>

> discussion. We could do a talk on it in Yokohama as well.

Hi Steven and thanks for this! It's a problem it's important to solve.

Some questions/thoughts after a very quick skim through:

>      A router MUST listen for all Neighbor Solicitations with a target
>      addresses from an assigned roaming prefix having the unspecified
>      address as the source address.  Similarly it MUST listen for all
>      Neighbor Advertisements with a target address from an assigned
>      roaming prefix and having the all-nodes multicast address as the
>      destination address.
>
>      A router MUST forward all such messages via global unicast to all
>      other routers having roaming interfaces sharing the roaming
>      prefixes the target address of the respective message belongs to.

(Similar language in section 3.2.)

Do I understand correctly that this will only happen for NS packets
destined for the globally scoped address? That is, no proxying of the
DAD messages for link-local addresses? Assuming clients don't re-start
DAD after having roamed from one BSS to another, isn't that a problem?

>     The IPv6 address fe80::1 SHOULD be used as fixed link-local
>     address exclusively by the router on roaming interfaces.

Isn't a more appropriate address to use for this the subnet-router
anycast address, i.e., fe80::? See RFC4291 section 2.6.1 - the intended
usage seems to be quite fitting for your use case:

   The Subnet-Router anycast address is intended to be used for
   applications where a node needs to communicate with any one of the
   set of routers.

Finally:

>     Stateful DHCPv6 MUST NOT be used to avoid the need to synchronize
>     lease information and relay DHCPv6 packets.

What about DHCPv6 Prefix Delegation? Not supported? I think there is a
use case for supporting PD to wireless clients if possible (think
virtual machines, 464xlat, etc.)

Tore

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 30 Nov 2015 14:40:38 +0100 (CET)

On Thu, 26 Nov 2015, Michael Thomas wrote:

> say, real time flows. Isn't this why you want to do make-before-break if 
> at all possible? at that point, time-to-flow is less of an issue, right?

I wasn't even aware that 802.11 can do make-before-break? A quick search 
seems to indicate that 802.11 roaming is strictly break-before-make?

---

From: Dave Taht <[email-masked]>
Date: Mon, 30 Nov 2015 14:55:18 +0100

On Mon, Nov 30, 2015 at 2:40 PM, Mikael Abrahamsson <[email-masked]> wrote:
>> Even if it's a 1/2 second, the l2 handover is still far too long for, say,
>> real time flows. Isn't this why you want to do make-before-break if at all
>> possible? at that point, time-to-flow is less of an issue, right?
>
>

Well, in the two or more radio (2.4 and 5ghz) case, you can easily
roam between the two radios with many chipsets. Some chipsets only
allow one active radio at a time, however.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 30 Nov 2015 15:04:53 +0100 (CET)

On Mon, 30 Nov 2015, Dave Taht wrote:

> Well, in the two or more radio (2.4 and 5ghz) case, you can easily roam 
> between the two radios with many chipsets. Some chipsets only allow one 
> active radio at a time, however.

Does this actually work in real life? Considering the solutions I found 
doing my quick search, it seems the AP vendors are implementing all kinds 
of solutions to trick the client that it's just one single large network 
with a single AP, even though it's a lot of them.

For instance: 
https://help.ubnt.com/hc/en-us/articles/205144590-UniFi-What-is-Zero-Handoff-

So while I would prefer a solution in the end with make-before-break and 
seamless handover without breaking the IP layer at all, this seems to 
involve quite a lot of new functionality both from the Network (which is 
doable) and from the client (also doable, but a lot harder, especially 
within current charter).

---

From: Dave Taht <[email-masked]>
Date: Mon, 30 Nov 2015 15:18:16 +0100

> Does this actually work in real life? Considering the solutions I found

Using linux, with ath9k gear, worked for 7 years. On nearly everything
else, rare.

> doing my quick search, it seems the AP vendors are implementing all kinds of
> solutions to trick the client that it's just one single large network with a
> single AP, even though it's a lot of them.
>
> For instance:

yes, it's a mess.

It's even worse than that...

> doable) and from the client (also doable, but a lot harder, especially

I would not mind at all if the ietf had a wg with the ieee and the
wifi alliance and whoever else might care, to make wifi better in a
huge variety of ways.

I remain perpetually astonished that a technology beloved by and used
by billions (with billions to come) has so few advocates, so few
working on actual interoperability, so many bad implementations, and
so little research funding.

the general public has their priorities straight:

https://www.google.se/search?q=image+hierarchy+of+needs+wifi&source=lnms&tbm=isch&sa=X&ved=0ahUKEwi32M36qbjJAhWEqnIKHSseCiMQ_AUIBygB&biw=1135&bih=1072

For those that haven't seen it:

https://www.youtube.com/watch?v=Rb-UnHDw02o

I am happy that a little bit of funding towards merely getting per
station queuing working looks to arrive next year.

Tackling handoff in any sane way with the current mess, looks harder.