Subject: [homenet] homenet: what now? ... next?

From: Stephen Farrell <[email-masked]>
Date: Fri, 1 Mar 2019 21:21:58 +0000

Dear WG,

At IETF-103 Ted lead a good discussion of where we're at and where we
and others in the homenet space may be heading. One key aspect of that
discussion is that we might (or might not) be working on specs that have
been overtaken by events e.g. in the sense that perhaps there are now
sufficient other options that people are less likely to implement the
specs we currently have as WG documents.

As chairs, we have also noted the relative lack of activity on the list
in recent months, which could also be related to a lack of interest in
implementing and deploying our current WG drafts.

We'd therefore like to have a discussion on the list, between now
and IETF-104 as to what the WG ought be doing.

It's fine to offer general opinions, but as a way to break it down, we
basically have two bits of work in-hand: (a) work on simple naming [1]
and (b) the drafts on handling names with help from your ISP. [2,3]
(We also have a chartered work item [4] on security that has seen no
progress but you can comment on that as item (c) if you like;-)

Ted also has some concrete ideas for work to do at the upcoming
hackathon. We've asked him to start a separate thread on that and
would love to see people participate in that.

We think there are a few potential positions that participants in the
discussion may have (or end up having) with respect to each of those,
perhaps:

(1) it's great work and I plan to implement or deploy - see
    you at the hackathon!
(2) it's great work and I'll be actively engaged with it in
    the coming months reviewing drafts and posting to the
    list
(3) I do care about this stuff getting done, but I don't have
    the time/management interest to spend the time I'd like.
(4) I'm not that interested in this stuff, but I don't object,
    and I'll read some drafts as I'm able to.
(5) it's fine stuff, but IMO not going to be used, so there's
    not much point in producing RFCs
(6) not sure at the moment, maybe the WG should go quiescent for
    a while 'till we know more

If one of those positions captures your opinion, feel free to respond
in shorthand. Otherwise, please tell us where you think we ought be
going, as a WG, with (a), (b) and/or (c).

To be clear, we're happy to proceed according to the consensus of the
WG participants whatever that may be. That could mean trying to
accelerate some work, or closing down the WG, or anything in between,
assuming we see enough engagement in discussion and that there's a
rough consensus that we can call.

As chairs, we want to allow plenty of time for this, and are considering
devoting (part of) a f2f session to bottoming out on this topic at
IETF-104 if that's needed, but we'd like to be reassured that the WG
think we're working on the right things now, and that those are likely
to be implemented and hopefully deployed.

We'd really appreciate it if you can send an initial response to
this mail in the next week so we can start to build an agenda for
our session at IETF-104.

Thanks
B&S. (As chairs)

[1] https://tools.ietf.org/html/draft-ietf-homenet-simple-naming
[2]
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation
[3]
https://tools.ietf.org/wg/homenet/draft-ietf-homenet-naming-architecture-dhc-options/
[4] https://tools.ietf.org/wg/homenet/charters

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Mar 2019 17:25:25 -0500

> going, as a WG, with (a), (b) and/or (c).

For me it’s (1) and (2).

I think there are a few reasons why homenet feels stalled right now.

We are tracking a moving target, and we haven’t adjusted our goals.   This is the conclusion I came to as a result of working on the presentation I did in Bangkok on Homenet Marketing.   I don’t think this is bad.
I conjecture that one of the reasons that there is good attendance at homenet but relatively limited participation is in fact that we are developing technology that is interesting to the people who are showing up, but not quite addressing their needs.
I don’t actually know what the applicability is for the hidden primary stuff.   I’ve gotten feedback that there are people who want this, but I have no idea what to do with it, given that we don’t want to expose internal DNS to external nodes.
No hardware that does homenet.   We have homenet stuff in OpenWRT, but making it work in a home isn’t a turnkey operation, and that is, after all, the goal of Homenet: a real network that sets itself up without the user having to grok how it works.
One of the applications of Homenet that we keep hearing about is the SOHO market.   We should target that explicitly and see what gaps exist in addressing it.

So I think spending some time re-targeting would be worthwhile, and it’s my intention to present a draft that talks about that in Prague.

I also would really like to see if anybody is willing to actually hack on Homenet in the hackathon.   There are a couple of projects I’d like to see us work on:
Turnkey homenet build of OpenWRT
If the Turris folks are down, it would be nice if they could join us and make it work in Turris OS as well.
Homenet-wide service discovery using the DNSSD Discovery proxy we’ve been working on, which is fully functional at this point.
Support for DNSSD SRP (this would involve finishing the SRP gateway I’ve been working on, and getting it to update Unbound or BIND).
Joining constrained-network edge routers to homenet routing and service discovery infrastructure
MUD support for devices that are not on a separate link, but are isolated from nodes that don’t have permission to talk to them.   This should be doable in OpenWRT.
Automatic IKEv2 tunnels on OpenWRT that use the new split DNS stuff being published in IPSECME to allow us to serve home.arpa to VPN clients.

This is an ambitious set of goals, and I don’t expect we’ll work on all of them, but these are things that need work, so if there is energy to work on any of them, it would be nice to see that happen at hackathon.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 1 Mar 2019 14:36:29 -0800

On 3/1/19 2:25 PM, Ted Lemon wrote:
> On Mar 1, 2019, at 4:21 PM, Stephen Farrell <[email-masked] 
> <mailto:[email-masked]>> wrote:

I would guess that even after 5 years, we still don't have much v6 
deployment into homes and that's a pretty big problem. Router vendors 
are not much motivated by that which doesn't have a market.

Sigh.

Mike

>
>   * We are tracking a moving target, and we haven’t adjusted our
>     goals.   This is the conclusion I came to as a result of working
>     on the presentation I did in Bangkok on Homenet Marketing.   I
>     don’t think this is bad.
>   * I conjecture that one of the reasons that there is good attendance
>     at homenet but relatively limited participation is in fact that we
>     are developing technology that is interesting to the people who
>     are showing up, but not quite addressing their needs.
>   * I don’t actually know what the applicability is for the hidden
>     primary stuff.   I’ve gotten feedback that there are people who
>     want this, but I have no idea what to do with it, given that we
>     don’t want to expose internal DNS to external nodes.
>   * No hardware that does homenet.   We have homenet stuff in OpenWRT,
>     but making it work in a home isn’t a turnkey operation, and that
>     is, after all, the goal of Homenet: a real network that sets
>     itself up without the user having to grok how it works.
>   * One of the applications of Homenet that we keep hearing about is
>     the SOHO market.   We should target that explicitly and see what
>     gaps exist in addressing it.
>
>
> So I think spending some time re-targeting would be worthwhile, and 
> it’s my intention to present a draft that talks about that in Prague.
>
> I also would really like to see if anybody is willing to actually hack 
> on Homenet in the hackathon.   There are a couple of projects I’d like 
> to see us work on:
>
>   * Turnkey homenet build of OpenWRT
>   * If the Turris folks are down, it would be nice if they could join
>     us and make it work in Turris OS as well.
>   * Homenet-wide service discovery using the DNSSD Discovery proxy
>     we’ve been working on, which is fully functional at this point.
>   * Support for DNSSD SRP (this would involve finishing the SRP
>     gateway I’ve been working on, and getting it to update Unbound or
>     BIND).
>   * Joining constrained-network edge routers to homenet routing and
>     service discovery infrastructure
>   * MUD support for devices that are not on a separate link, but are
>     isolated from nodes that don’t have permission to talk to them.  
>     This should be doable in OpenWRT.
>   * Automatic IKEv2 tunnels on OpenWRT that use the new split DNS
>     stuff being published in IPSECME to allow us to serve home.arpa to
>     VPN clients.
>
>
> This is an ambitious set of goals, and I don’t expect we’ll work on 
> all of them, but these are things that need work, so if there is 
> energy to work on any of them, it would be nice to see that happen at 
> hackathon.
>
>
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 1 Mar 2019 23:49:06 +0000

> I would guess that even after 5 years, we still don't have much
> v6 deployment into homes and that's a pretty big problem. 

That's an interesting statement to make. Do you have evidence of that?
https://www.worldipv6launch.org/measurements/ shows considerable deployment. I know for a fact that the AT&T wireline network supports IPv6 to 100% of customers. The reason only 61.26% of traffic is IPv6 is *not* due to the ISP not supporting it. It's due to edge networks that don't support. And in this case, it's mostly due to enterprises not supporting. The 61.26% number is heavily weighted towards mass market customers using IPv6, because it was easier to push IPv6 support into managed CE routers.

What I *am* seeing, is a lack of random topology multi-router networks.
While it may be that continued use of IPv4 in home networks is a factor that drives people away from multi-router topologies, I don't think this is the same as saying that lack of IPv6 is a reason people aren't deploying.
I really don't think IPv6 (or even IPv6-only inside the mass market LAN -- which won't be happening for a long time) is a driver for multiple routers.
The biggest driver historically has been to get multiple Wi-Fi access points, to cover more of the premises. But many people resisted even this driver, because devices didn't seamlessly move between APs and the routed interfaces blocked multicast traffic (so you could only cast to your TV if you were on the same AP with the TV).

But Wi-Fi Alliance (WFA) has been working to provide a solution for seamless whole home coverage. And from what I can see, I think it's going to be successful. But WFA EasyMesh (release 1) is a tree-topology L2 bridged network. I do think this needs to move towards true mesh (and the reason they haven't is because they haven't yet been properly introduced to an easy method of loop avoidance). 

So if multi-access points was a driver for multiple routers, WFA EasyMesh may very well kill that off as a driver.

But even if the common home network won't have lots of routers, the need for a good naming architecture still exists, IMO.
And the need for good loop avoidance...

This is my personal, individual opinion, if that wasn't obvious.
Barbara

---

From: Michael Thomas <[email-masked]>
Date: Fri, 1 Mar 2019 16:09:03 -0800

> https://www.worldipv6launch.org/measurements/ shows considerable deployment. I know for a fact that the AT&T wireline network supports IPv6 to 100% of customers. The reason only 61.26% of traffic i…

Oh, that's interesting. I knew it was getting support on mobile, but 
haven't kept up on what's going on cable/dsl/fiber.

> I really don't think IPv6 (or even IPv6-only inside the mass market LAN -- which won't be happening for a long time) is a driver for multiple routers.
What I meant is that homenet router protocols are v6 only. At least the 
last time I checked.
> The biggest driver historically has been to get multiple Wi-Fi access points, to cover more of the premises. But many people resisted even this driver, because devices didn't seamlessly move betwee…

Yeah, I have that problem with my friends/neighbors.

> But Wi-Fi Alliance (WFA) has been working to provide a solution for seamless whole home coverage. And from what I can see, I think it's going to be successful. But WFA EasyMesh (release 1) is a tre…

Do you know if they deal with differences in the security domains? Or is 
it punted to L3? Like in my example, I might want to let my neighbors 
access my hot tub controller, but not, say, my tv. You can envision the 
same thing with guest/kids nets.

> But even if the common home network won't have lots of routers, the need for a good naming architecture still exists, IMO.

Yes, and that's not dependent on v6 afaik.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Mar 2019 19:14:30 -0500

Michael Thomas <[email-masked]> wrote:
    > deployment
    > into homes and that's a pretty big problem. Router vendors are not much
    > motivated by that which doesn't have a market.

Cable ISPs in north america (Rogers, Comcast) seem to be turning more and
more IPv6 on daily.  I am going by increasingly visible IPv6 (including ULAs,
btw) at local pubs/restaurants/coffee shops.  But, IPv6 is at this point, a
non-event for users (that's good that they don't notice, btw).

I personally do not believe that Home Router firmware update practices have
significantly improved.  I would welcome more recent data: is anyone
collecting this on a regular basis?  I suspect that 90% of firmware updates
occur because the (integrated) modem is replaced in order to upgrade
bandwidth.

For the last 10 to 15 years the ISP-provided home router has come to dominate
the market, with the belief by the ISPs that this is a MUST that they control
the device.  Many (but not all) at the IETF do not share this view, but most
non-technical users see the ISP provided router is simply saving the trip to
BestBuy, rather than an abdication of control over their home.   If this
trend continues, then I believe that ISPs (residential IAPs) will come to
want to control all IoT devices in the home -- because security -- telling
residential customers what they can and not connect.

I believe that this direction will result in ISPs being 100% liable for
attacks on critical infrastructure; I don't think that this is a place that
ISPs want to be, but I'm not sure that they have understood this yet.

It's clearly not in
Amazon/Google/Facebook/Intel/Samsung/insert-another-IoT-conglomerate's
interest to be told by ISPs what their products may or may not do.
This is an ongoing tussle that that relates in some ways (but not all) to the
net neutrality debate and the desire my ISPs for a cut of the over-top-pie.
My answer is that the consumer should be in control, and that ISPs need to
get out of the home router business entirely.  Home router vendors (or the
service companies they create) should provide first-level support for issues,
and actual real connectivity issues should be submitted electronically.  Not
so different in the way that my furnace maintenance is not provided by my gas
supplier, but my gas supplier gets to inspect the hookup.

When we started this effort we heard of real situations such as Fred's
original FUN BOF slides on how dual-geek households are forced not to share
printers due to corporate home firewall requirements.  And that we should
expect the situation to get worse.  Those slides are close to ten years old.
I'd like to know if they are still at relevant.  Maybe they aren't.
If not, why not?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Thomas <[email-masked]>
Date: Fri, 1 Mar 2019 16:24:31 -0800

> I'd like to know if they are still at relevant.  Maybe they aren't.
I've been in startup land the last several years where everything is in 
the cloud and everybody brings their own device. At the office, it was 
just business cable. We got asked by a customer what our firewall was 
and we sort of looked puzzled. Where do you mean? There was no corporate 
network and no need for one. We outsourced all of the typical things 
that corpro IT does which was fine by us because who wants to spend time 
and money on reinventing wheels?

My point here is that companies who are started in the cloud -- which is 
just about everybody these days -- don't even understand the 
requirement. Maybe they do when they get big enough, but I'm not sure.

Mike

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sat, 2 Mar 2019 00:49:09 +0000

> > But Wi-Fi Alliance (WFA) has been working to provide a solution for
> seamless whole home coverage. And from what I can see, I think it's going to
> be successful. But WFA EasyMesh (release 1) is a tree-topology L2 bridged
> network. I do think this needs to move towards true mesh (and the reason
> they haven't is because they haven't yet been properly introduced to an
> easy method of loop avoidance).
> 
> 

Release 1 did not. 
Here is the Release 1 spec: https://www.wi-fi.org/file/multi-ap-specification-v10
They do make non-members provide contact info, but the download is free.

Release 2 hasn't been released, yet. And I've pledged to abide by their non-disclosure policies, so I can't tell non-members what's in it. I think it's safe to say, it adds functionality that many companies find desirable.
Barbara

---

From: "Ralf Weber" <[email-masked]>
Date: Sat, 02 Mar 2019 09:15:03 +0100

Moin!

> occur because the (integrated) modem is replaced in order to upgrade
So you think this is a problem.

> BestBuy, rather than an abdication of control over their home.
And I agree with most of the non-technical end users there. An ISP 
provided
router does get updates and in case of problems I can call them and they 
will
fix it. I currently experience that myself as my DSL modem (not ISP 
supplied)
is currently experiencing problems, which the ISP provided router does 
not
have. So I now have to research what the actual problem is, which is 
something
most non technical users wouldn’t be even capable of doing.

Also I’ve seen way more intrusion of my home and privacy by over the 
top
providers or IoT devices than I have seen by my ISP. I know this might 
be
different in different parts of the world, which is why we should not 
take
either view for granted.

> get out of the home router business entirely.
I agree that customers should be in control, and they are now as in most
countries you can choose between an ISP provided routers or buy one at 
your
convenience. I do not see how less choice (only non ISP provided 
routers)
will make this better especially as ISP provided and often managed 
routers
are usually updated and taken care of by the ISP in case of problems.

> Home router vendors (or the
> and actual real connectivity issues should be submitted 
> electronically.
Well I wish I had a pony, but sorry this is not how it works. The 
primary
driver for most people when they buy home routers is price and I doubt 
that
these mostly Asia based companies could support my wider family with a
german speaking hotline. My ISP can though…

On Stephens original question I am between 3 and 4, as I mostly care 
from
an intellectual standpoint, as in man it would be great if that would 
work,
rather then believe we will actually get devices widely deployed, but I 
for
sure would like to play with some in my free time.

So long
-Ralf
—--
Ralf Weber

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 02 Mar 2019 17:30:33 +0100

> What I meant is that homenet router protocols are v6 only.

No, they're not.

Both HNCP and Babel carry their control traffic over link-local IPv6, but
they support both IPv4 and IPv6 with almost equal functionality.

(The only significant difference is the treatment of border routers, which
are assumed to be doing NAT in IPv4 and stateless routing in IPv6.)

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Sat, 2 Mar 2019 11:42:43 -0500

> they support both IPv4 and IPv6 with almost equal functionality.

This is one of the reasons that I would like us to get together and hack on this at the hackathon: in fact while what you are saying is technically true, in practice IPv4 _is_ treated like a second-class citizen in the sense that if your ISP-provided public IP address ever goes away, all of your RFC1918 addresses on the homenet also go away.

So on a practical level, homenets as currently specified really are, if not v6-only, then at least only-v6-reliable.

I think it would actually be better if homenets were IPv6-only, with NAT64 at the edge for the case where there is only an IPv4 address, but I imagine that this would not be a popular enough view to get consensus.  It would be equally good if IPv4 were just assumed to be required to work regardless of whether there’s an upstream IPv4 address.   This is something that we should really re-think—the way it is now isn’t ideal.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 2 Mar 2019 10:17:08 -0800

> are assumed to be doing NAT in IPv4 and stateless routing in IPv6.)

Oh, I thought the charter was for v6 only. Did that change, or am I 
misremembering?

Mike

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Mar 2019 14:42:50 -0500

> So you think this is a problem.

I'm saying that the devices are not getting updates, even ISP provided
ones.

    > And I agree with most of the non-technical end users there. An ISP provided
    > router does get updates and in case of problems I can call them and

I do not observe ISP provided modems to get updates.

    > countries you can choose between an ISP provided routers or buy one at your
    > convenience. I do not see how less choice (only non ISP provided routers)
    > will make this better especially as ISP provided and often managed routers

There are quite a number of services in Canada where the ISP provided
modem/router combo has no way to go into a layer-2 only mode.  Or it's very
hard to figure out, or the ISP disdains all notions of supporting you.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sat, 2 Mar 2019 20:37:03 +0000

> For the last 10 to 15 years the ISP-provided home router has come to
> dominate the market, with the belief by the ISPs that this is a MUST that they
> control the device.  Many (but not all) at the IETF do not share this view, but
> most non-technical users see the ISP provided router is simply saving the trip
> to
> trend continues, then I believe that ISPs (residential IAPs) will come to want
> to control all IoT devices in the home -- because security -- telling residential
> customers what they can and not connect.

Just to be clear, the main reasons most ISPs require use of the ISP CE router at the edge of mass market customer networks is because:
1. Providing instructions for installation and setup becomes easier, as well as ensuring the installation process is as trouble-free and easy as possible.
2. Improved but simplified security between the CE router and the access network
3. Cost of help desk support is greatly reduced because help desk personnel only have to know how to guide customers through one GUI, and the help desk can get permission from the customer (when on a call with the customer) to directly manage the router if the customer prefers that approach.

The cost of supporting a customer under a bring-your-own-random-CE-router model is considerably higher than the cost of supporting a customer in an ISP-managed/specified/provided-CE-router model.

None of which prevents anyone from putting their own router between the ISP CE router and their home network. That's what I do. The ISP doesn't control my home network and there's no requirement from the ISP that they control my home network. I have not abdicated control of my home network to my ISP.

Home automation services may be offered by an ISP, but I'm not aware of any case in the US (or Europe) where someone who wants home automation / security is required to get it from their ISP or where the ISP has to give permission for someone else (or for the homeowner) to operate such a service. I don't know the rest of the world.

Can we please avoid making these rather insulting and inflammatory claims without evidence? If there's evidence, please provide it. If the evidence indicates the practice is localized (to a single ISP, country, or geography), please note that when providing evidence. Broad claims that an entire IETF-stakeholder group is evil and trying to control everything are not nice.

> I believe that this direction will result in ISPs being 100% liable for attacks on
> critical infrastructure; I don't think that this is a place that ISPs want to be, but
> I'm not sure that they have understood this yet.

I don't know about other ISPs, but I do know my employer takes network security very seriously. And access network security (including preventing theft of a customer's access service) is one of the reasons I mentioned for providing customers with an ISP-provided CE router.

> This is an ongoing tussle that that relates in some ways (but not all) to the net
> neutrality debate and the desire my ISPs for a cut of the over-top-pie.
> and actual real connectivity issues should be submitted electronically.  Not so
> different in the way that my furnace maintenance is not provided by my gas

No ISP in the US is in a position to tell these companies what they can or can't do in a device connected to a customer's network. I can't speak for other regions.
There is no evidence that all ISP routers provided by all ISPs in every corner of the world prevent all of their customers from being in complete control of the home network.  
I remain in complete control of my home network and the devices connected to it, independent of the fact that my home network edge router is connected through an ISP CE router. Therefore, I know this claim is false in my case.
In any case, I think this comment is well outside the realm of the homenet charter.

<I'm getting really tired of being regularly insulted with unsubstantiated claims. So I'm starting to fight back.>

Barbara

> When we started this effort we heard of real situations such as Fred's original
> FUN BOF slides on how dual-geek households are forced not to share

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sat, 2 Mar 2019 19:42:54 +0000

... if your ISP-provided public IP address ever goes away, all of your RFC1918 addresses on the homenet also go away.

<bhs> Not in any router I’ve ever had a hand in specifying or procuring! And not true of my Netgear router, or any of my older Linksys routers. Or OpenWRT loaded routers. My RFC1918 addresses absolutely stay put. I just can’t access the Internet (through that broadband connection) when my ISP-provided public IP address goes away. I’m not aware of any router that loses its RFC1918 addresses when the WAN goes down.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 03 Mar 2019 02:50:20 +0100

> in fact while what you are saying is technically true, in practice IPv4
> _is_ treated like a second-class citizen in the sense that if your
> ISP-provided public IP address ever goes away, all of your RFC1918
> addresses on the homenet also go away.

That's an property of the hnetd implementation, not a feature of the
protocol (and it doesn't apply to shncpd).  See RFC 7788 Section 6.5.

> This is one of the reasons that I would like us to get together and hack on
> this at the hackathon:

It should be an easy fix, feel free to go ahead.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Sat, 2 Mar 2019 21:08:31 -0500

> protocol (and it doesn't apply to shncpd).  See RFC 7788 Section 6.5.

The text:

      An HNCP router MUST create a private IPv4 prefix [RFC1918 <https://tools.ietf.org/html/rfc1918>]
      whenever it wishes to provide IPv4 Internet connectivity to the
      network and no other private IPv4 prefix with Internet
      connectivity currently exists.  It MAY also enable local IPv4
      connectivity by creating a private IPv4 prefix if no IPv4 prefix
      exists but MUST NOT do so otherwise.

So it does allow the implementation to use use RFC1918 addresses internally when there is no upstream address, but it really does seem to be saying that’s not necessary.   Better advice would be that if an IPv4 address is ever obtained externally, that internal RFC1918 addressing should remain available until some substantial amount of time has passed.   Right now this behavior is optional.

> It should be an easy fix, feel free to go ahead.

The point of soliciting participation at hackathon is for us to gain collective experience on the easy or difficulty of deploying homenet in practice.   It’s all very well and good to have implementations, but if nobody is able to use them, this isn’t really what we want when we talk about having interoperating implementations.   This is particularly true when the goal of a body of work is automatic operation (as in ops), as opposed to mere protocol interoperation.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 03 Mar 2019 03:09:12 +0100

> Oh, I thought the charter was for v6 only.  Did that change, or am
> I misremembering?

Yeah, I never understood that.  The charter is pretty much v6-only, but
I don't recall anyone ever suggesting that we should omit IPv4 support
(but then, I only got involved around the summer of 2014).  RFC 7788 says:

   While RFC 7368 sets no requirements for IPv4 support, HNCP aims to
   support the dual-stack mode of operation, and therefore the
   functionality is designed with that in mind.

while the Babel profile for Homenet says:

   REQ3: a Homenet implementation of Babel SHOULD implement the IPv4
   subset of the protocol

The implementation status is pretty solid:

  - both implementations of HNCP (hnetd and shncpd) have good support for
    IPv4 and DHCPv4;
  - of the six implementations of Babel known to me, four support IPv4
    (babeld, BIRD, FRR and David's Top Secret Implementation).

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 03 Mar 2019 12:45:20 +0100

> The point of soliciting participation at hackathon is for us to gain
> collective experience on the easy or difficulty of deploying homenet in
> practice.

Oh, that's different, and not at all the motivation you give in your
previous mail.  Experience shows that the best way to make something
happen is to organise it oneself, and therefore you should feel free to
organise a Homenet tutorial yourself, just like you should feel free to
fix yourself the issues you're having with hnetd.

I'm not sure that you'll find much of an audience, though -- as you
rightly point out, there doesn't appear to be much excitement left around
Homenet, and the main contributors appear to have moved on with their
lives.  It's been six years, after all.  (For my part, my IETF funding
runs out in September.)

On that subject, you might remember the talk I gave about HNCP deployment
back in 2016.  The conclusions were that a first year student who had
never done any networking before was able to deploy an HNCP+Babel mesh
network in two weeks, and most of that time was spent learning to reflash
off-the-shelf routers from scratch.

    https://datatracker.ietf.org/meeting/96/materials/slides-96-homenet-1

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Sun, 3 Mar 2019 09:59:48 -0500

I do remember that talk. CS grad students are not our target market. Open
source distributions are a great demo, but I want this stuff in Ubiquiti
routers, Eero routers, etc.  it’s clear you aren’t interested in working on
it at the Hackathon, which is perfectly understandable, but I was asking if
anyone *is *interested because i can’t do it all by myself.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 04 Mar 2019 01:00:56 +0100

> I do remember that talk. CS grad students are not our target market.

First year undergrad, Ted.  Eighteen year-old lass with no previous
networking experience.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 04 Mar 2019 01:16:18 +0100

> Does that equality mean that I can route from a device in one home to a device
> in another over v4.

You'll need something like ICE (RFC 8445), or at least STUN (of which ICE
is a superset).  PCP (or NAT-PMP) should in principle work too, but
I haven't actually tried getting it to work over multiple hops.

You'll need ICE STUN or PCP even for IPv6, since people appear to be
intent on putting stateful IPv6 firewalls on their edge routers.

> Won’t they both have rfc 1918 addresses (possibly the same ones).

ICE is fine with that.

-- Juliusz

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 7 Mar 2019 14:51:33 +0000

Hi all,

We'd really appreciate more feedback on this topic,
so could you please take a few minutes to give us
some more guidance on where you want to see the
work go from here...

Thanks,
S.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 08 Mar 2019 13:48:50 +0100

Hi Stephen,

Sorry if I'm repeating myself -- I've already expressed the opinions
below, both at the mike and on the list.

> (a) work on simple naming

I think that this work should be stalled until we have an implementation
to play with and make some in vivo experiments.  (Experience shows that
the best way to break a protocol is to give an implementation to Dave.)

> (b) the drafts on handling names with help from your ISP.

I fear that these drafts are a bad case of complexity for the sake of
complexity (or perhaps a case of involving the ISP for the sake of
involving the ISP).  I still haven't seen a compelling argument that they
do solve a problem that a trivial end-to-end protocol wouldn't solve.
Back in July 2018, I wrote the following:

    This is a question that I've been asking since July 2014, and I still
    haven't received an answer I could understand.

Please see the thread starting on 18 July 2018:

    https://www.mail-archive.com/[email-masked]/msg07012.html

> progress but you can comment on that as item (c) if you like;-)

Some pointers for the rare people who don't spend most of their leisure
time reading Internet-Drafts:

  - HNCP is based on DNCP, which includes a security mechanism designed to
    provide authenticity, integrity and confidentiality of the HNCP data:

        RFC 7525 Section 8

    I believe that this is implemented in hnetd.  (Yeah, Markus and
    Stephen did some remarkable work.)

  - Babel has two security mechanisms:

        https://tools.ietf.org/html/draft-ietf-babel-hmac
        https://tools.ietf.org/html/draft-ietf-babel-dtls

    There appear to be no standards-track key distribution and rotation
    protocols for either of OSPF, IS-IS, BGP or BFD (static keying seems
    to be the norm), so a natural question is whether HNCP could serve
    this purpose, or whether it would be better to use a dedicated key
    distribution and rotation mechanism.

  - RFC 3971 Section 6 says the following:

       To protect Router Discovery, SEND requires that routers be
       authorized to act as routers.  This authorization is provisioned in
       both routers and hosts.

    Since hosts don't participate in HNCP, it is not clear if HNCP can be
    used as a SEND trust anchor.  I believe there's the same issue with
    securing access the DNS stub resolver (DNSCrypt, DNS over TLS, etc.).

-- Juliusz

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 8 Mar 2019 13:05:11 +0000

Hiya,

Given the level of list inactivity, it's actually really
helpful that you took the time to re-tx those points!

One clarifying question below...

On 08/03/2019 12:48, Juliusz Chroboczek wrote:
> to play with and make some in vivo experiments. 

Our (chairs), plan for that has been to try help the WG get the
draft to the point where one would normally do a WGLC and to then
hold off on that WGLC, waiting for the kind of implementation
experience you mention. Given the level (i.e., lack) of engagement
though, I'm wondering if that's still a viable plan, despite the
good work Ted and others continue to do it this space.

I'm not sure if by "stalled" you mean sticking with the plan above,
or something else (e.g., for the WG to go entirely quiescent until
the authors come back and claim the draft is done and have running
code). Can you clarify?

Thanks,
S.

> (Experience shows that

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 08 Mar 2019 14:36:56 +0100

> I'm not sure if by "stalled" you mean sticking with the plan above, or
> something else

I'm concerned about two things:

  - if you're not implementing yourself, everything seems easy, and you
    end up with an overly complex design;
  - once you've spent a lot of time on a paper protocol, you're unwilling
    to change things even when the implementation work indicates they're
    broken, so you end up with a design that is not only overly complex,
    but doesn't work very well.

I think this protocol has reached the point where any further paper work
will be counter-productive until somebody tries their hand at implementing
it.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Mar 2019 09:41:23 -0500

> will be counter-productive until somebody tries their hand at implementing

Which protocol?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Mar 2019 10:09:56 -0500

> the best way to break a protocol is to give an implementation to Dave.)

We have a working dnssd discovery proxy and client.   What we don’t have is those things connected via hncpd.   That is one of the things I would like to work on at the hackathon, if there is interest.

>   Stephen did some remarkable work.)

I had indeed missed this—thanks for pointing it out.   However, I have no idea how to configure it with existing software.   This is also something I’d like to work on at the hackathon: can we actually use this mechanism?   Can we come up with a way to set it up in OpenWRT that people who are not networking grad students can deploy?

>       https://tools.ietf.org/html/draft-ietf-babel-hmac <https://tools.ietf.org/html/draft-ietf-babel-hmac>
>       https://tools.ietf.org/html/draft-ietf-babel-dtls <https://tools.ietf.org/html/draft-ietf-babel-dtls>
> 

HNCP can’t be used by hosts to establish trust, as currently specified.   We don’t really have an answer to the host enrollment problem at present, unfortunately.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Mar 2019 22:01:17 +0100 (CET)

> residential customers what they can and not connect.

I have data from some ISPs here pointing to 1% of the customers setting 
the media converter/router into bridge mode and providing their own HGW. 
Most people just keep whatever the ISP provided them with. Looking at the 
SSIDs I see, typically people don't even change the SSIDs/passwords from 
what came out of the box.

A multi-router home isn't on the product managers radar. Their biggest 
issue right now, is customers complaining about bad service and most of 
the time this is related to bad wifi for the last 0-30 meters of access 
to the end-user device.

If HOMENET somehow could help solve that problem (diagnosing bad wifi and 
helping the ISP/customer figure out what's wrong and what needs to be 
done) then HOMENET might get onto the radar and be of interest.

The good thing is that the HGW is going from an unloved cost-cut necessity 
into a more important device that is a lot higher end device. It's gone 
from a 2-4MB flash / 16 MB RAM device, to nowadays often having 128-512MB 
RAM and 32-128MB flash (or even more). It now also is more likely to have 
aN ARM processor which is several times faster than the devices of 5-10 
years ago. A negative though, is that it's also very likely to contain a 
packet accelerator that is quite constrained in what it can and can't do 
acceleration of. This might make some use-cases harder to achieve. Speeds 
have gone up and nowadays having 4x4 wifi chips in there that'll in 
practice support actual transport payload speeds of upwards of 1 gigabit/s 
on wifi isn't uncommon. We're also now seeing devices with even higher 
port speeds than 1GE, but that might take a bit longer to reach wider 
adoption.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 13 Mar 2019 22:13:17 +0100

Mikael Abrahamsson <[email-masked]> writes:

>> dominate the market, with the belief by the ISPs that this is a MUST
>> that they control the device. Many (but not all) at the IETF do not
>> share this view, but most non-technical users see the ISP provided
>> router is simply saving the trip to BestBuy, rather than an
>> abdication of control over their home. If this trend continues, then
>> I believe that ISPs (residential IAPs) will come to want to control
>> all IoT devices in the home -- because security -- telling
> I have data from some ISPs here pointing to 1% of the customers
> setting the media converter/router into bridge mode and providing
> their own HGW. Most people just keep whatever the ISP provided them
> with. Looking at the SSIDs I see, typically people don't even change
> the SSIDs/passwords from what came out of the box.
>
> issue right now, is customers complaining about bad service and most
> of the time this is related to bad wifi for the last 0-30 meters of
> access to the end-user device.
>
> If HOMENET somehow could help solve that problem (diagnosing bad wifi
> and helping the ISP/customer figure out what's wrong and what needs to
> be done) then HOMENET might get onto the radar and be of interest.
>
> The good thing is that the HGW is going from an unloved cost-cut
> necessity into a more important device that is a lot higher end
> device. It's gone from a 2-4MB flash / 16 MB RAM device, to nowadays
> often having 128-512MB RAM and 32-128MB flash (or even more). It now
> also is more likely to have aN ARM processor which is several times
> faster than the devices of 5-10 years ago. A negative though, is that
> it's also very likely to contain a packet accelerator that is quite
> constrained in what it can and can't do acceleration of. This might
> make some use-cases harder to achieve. Speeds have gone up and
> nowadays having 4x4 wifi chips in there that'll in practice support
> actual transport payload speeds of upwards of 1 gigabit/s on wifi
> isn't uncommon. We're also now seeing devices with even higher port
> speeds than 1GE, but that might take a bit longer to reach wider
> adoption.

Since you seem to be pretty up to date on the ISP-level CPE offerings,
just out of curiosity: Do any of these fancy ARM boxes include actual
fixes for bufferbloat? :)

-Toke

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Mar 2019 08:26:43 +0100 (CET)

> fixes for bufferbloat? :)

Short answer, no.

Bufferbloat isn't on the radar of any product managers I have talked to. 
Cable Labs is the only organisation that seems to do anything about this 
that I have seen.

I have made statements previously in that context of most newer higer end 
devices having packet accelerators which doesn't lend itself to FQ_CODEL 
and the rest of the mechanisms the bufferbloat movement has gravitated 
towards, but I still feel what I said wasn't really accepted and "taken 
in".

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 14 Mar 2019 11:40:15 +0100

Mikael Abrahamsson <[email-masked]> writes:

> Bufferbloat isn't on the radar of any product managers I have talked
> to. Cable Labs is the only organisation that seems to do anything
> about this that I have seen.

Right, yeah, that's what I thought. :/

> I have made statements previously in that context of most newer higer
> end devices having packet accelerators which doesn't lend itself to
> FQ_CODEL and the rest of the mechanisms the bufferbloat movement has
> gravitated towards, but I still feel what I said wasn't really
> accepted and "taken in".

Well, for my part I have mentally filed this under "vendors don't care",
which has been my impression the whole time (with a few exceptions).
It's terribly frustrating, but it's not like there's anything I can
really do about it, so I've more or less resigned myself to this.

You're right that packet accelerators complicate things a bit. I'm not
entirely convinced that the "doesn't lend itself to FQ-CoDel and the
rest of the mechanisms the bufferbloat movement has gravitated towards"
actually *has* to be true, but it's harder to do a proof of concept
since the barrier to entry for hardware development is higher. So I
doubt anything is likely to happen here unless someone with the
resources to do hardware development steps up.

But anyway, thanks for confirming by suspicions :)

-Toke

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Mar 2019 13:53:49 +0100 (CET)

> resources to do hardware development steps up.

The people with hardware experience want to do PIE, because it lends 
itself better for implementation in existing hardware, or hardware with 
small modification.

Sometimes it's better to accept non-perfect more easily implementable 
solutions that solves most of the problem space, instead of aiming for the 
"perfect one" and getting nothing.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 14 Mar 2019 14:48:30 +0100

Mikael Abrahamsson <[email-masked]> writes:

> itself better for implementation in existing hardware, or hardware
> with small modification.
>
> solutions that solves most of the problem space, instead of aiming for
> the "perfect one" and getting nothing.

Absolutely, I'm all for that. But even something that is as
retrofitable[0] as PIE is not getting implemented... So then what to do?
This makes it difficult to motivate spending more resources on doing
more work in this area... :/

-Toke

[0] "Retrofitable" is totally a word...

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 15 Mar 2019 01:45:26 +0100

> PIE [...] lends itself better for implementation in existing hardware,
> or hardware with small modification.

Could one of you please explain why?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 15 Mar 2019 09:24:14 +0100 (CET)

> Could one of you please explain why?

Packet accelerators work either by completely autonomously forwarding 
packet without CPU involvement, or it works by flow offload. This 
basically means that on this kind of hardware if you tcpdump packets 
you'll see the first TCP handshake packets and then kernel sees nothing. 
It's now offloaded to the packet forwarding hardware, including all 
queueing decisions.

I am not an expert on exact implementations, but WRED is available on a 
lot of platforms. PIE seems to be taking a stance in WRED and adding a bit 
of control logic on top of it, and that's that. It means PIE has a 
possibility to be retrofitted onto older hardware.

FQ part of FQ_CODEL means you need to have a lot of queues, and you need 
to L4 hash onto these different queues. That's just not possible on a lot 
of HW.

I don't know if CODEL can be retrofitted onto WRED style HW, but I don't 
think so.

My observation has been that the bufferbloat movement has focused on 
academic excellence and making this work on the platforms they have 
available to them. Nothing wrong with that and the results are great, it's 
just not applicable to a lot of equipment out there that it should be 
applicable to.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 15 Mar 2019 13:34:52 +0100

> Could one of you please explain why?

With the caveat that I have never worked with any of this hardware, this
is my understanding:

Basically, you can re-use the drop mechanism from RED and use the PIE
algorithm as a (better) way to control the setpoints. This makes it
possible to retrofit it in existing hardware. In fact I believe you can
implement PIE entirely in the (software) control plane on (a lot of)
gear that already knows how to do RED.

-Toke

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 15 Mar 2019 11:08:37 -0400

> gear that already knows how to do RED.
Another factor, which as I recall was perhaps the strongest of the 
original motivations for PIE, is that PIE does nearly all its work on 
enqueue, whereas CoDel does most of its work on dequeue. In many 
hardware interfaces, especially at a head end where there are lots of 
queues and a simple hardware FIFO feeding the link, it turns out to be 
difficult/expensive to insert the computations CoDel does on each 
dequeue operation.

> -Toke

DaveO

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 15 Mar 2019 22:41:07 +0100

> difficult/expensive to insert the computations CoDel does on each

Ah, I see. I guess that makes sense. Although I have also seen someone
implement CoDel in a "virtual queueing" setting where all computation is
done on enqueue and the sojourn time is simulated ahead of time. You
can't do this in all scenarios, but probably in more than one might
think... Obviously it would require a bit of work to go from the spec
(or reference implementation) to that, but it's definitely possible.

-Toke