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

[Ray Hunter (v6ops)]

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, internet-dra...@ietf.org 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
homenet@ietf.org
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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Mikael Abrahamsson]

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


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.


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?


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?


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 Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Michael Thomas]

On 11/26/2015 07:15 AM, Mikael Abrahamsson wrote:

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


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.


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?


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?


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?




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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Michael Thomas]

On 11/26/2015 08:49 AM, Juliusz Chroboczek wrote:

Hmm. I've also setup many small PKIs and don't agree. I do think someone
could easily make all that quite usable within the home.

Have you ever walked a non-specialist through the process?




I'm not Stephen, and I don't play Stephen on teevee, but anything you 
can do with pre-shared keys, you
can do with with an asymmetric keying approach too. Pre-shared keys are 
pretty high touch form of enrollment,
after all. If you can get away with leap-of-faith kinds of enrollment, 
it is even easier IMO because you don't have

to remember messy and/or lousy keys/passphrases:

New Thingy: "I'm blah and want to enroll! my public key is blah-blah-blah"
Enroller: "Sure!" or "Nah, you look sketchy"

Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Henning Rogge]

On Thu, Nov 26, 2015 at 5:49 PM, Juliusz Chroboczek
 wrote:
>> Hmm. I've also setup many small PKIs and don't agree. I do think someone
>> could easily make all that quite usable within the home.
>
> Have you ever walked a non-specialist through the process?

I wonder why this could not be fully automatic?

Setup a "press button for first login" system similar to WPS for Wifi
that deploys the certificate.

No need for the user to do something complicated.

Henning

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Stephen Farrell's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

[Stephen Farrell]

On 26/11/15 16:49, Juliusz Chroboczek wrote:
>> Hmm. I've also setup many small PKIs and don't agree. I do think someone
>> could easily make all that quite usable within the home.
> 
> Have you ever walked a non-specialist through the process?

I have not. But as others said, the key idea would be to make
it as invisible as possible, which is quite doable. And the
tools are there these days (much moreso than even 5-6 years
ago) in pretty much all platforms/languages.

S.

> 
> -- Juliusz
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet