Re: [homenet] Support for RFC 7084 on shipping devices...

[Ole Troan <[e-mail]>]

>>>> Homenet has solved the problem of self-configuring networks in arbitrary topologies.
>>> 
>>> If that were true, I wouldn’t be asking this question.  We’re still chugging along, but we don’t have something that nay router vender could even consider shipping right now. There isn’t enough participation in homenet anymore for us to really iron out the kinks.  Certainly if I could count o homenet being present in routers in the home, we wouldn’t be having this conversation! :)
>> 
>> Since this was sent to an IETF list I assumed you were focused on standards. (And presumably also running code). :-)
> 
> It’s the running code that’s the problem.  What I’m hunting around for is whether there are some things we need to do that we haven’t yet done.   I wish I could say “just turn on Homenet and everything will be fine,” but we aren’t in a position to say that yet.   If people are feeling satisfied that homenet is “done,” we (the IETF, and the Internet community in general) have a problem.
> 
> We’d been tempted to punt on this because there are perfectly good commercial solutions that solve this problem with L2 bridging, but those don’t work when you need to route between WiFi and e.g. 6lowpan networks.

Are you saying there might be gaps in HNCP? Or things we could do to make it more deployable?
If it's just a matter of running code missing, I'm not sure defining anything else new in the IETF would help that problem.

I know why I haven't implemented HNCP on software I work on... and I also know that there aren't any very realistic alternatives either.

>>>> - single router and bridging (7084)
>>> 
>>> If it doesn’t filter RA, and I control the second router, I’m okay, right?
>> 
>> Well, yes it isn't a router at that point, it's a bridge.
> 
> The reason I mentioned this particular problem is that I’ve heard reports of 7084 routers implementing RA guard, which sort of makes sense, but it totally breaks this use case.

RA guard isn't applicable in a RFC7084 context. RFC7078 talks about routing and routers. I.e. what happens at the network layer.
If you are talking about what happens at the often integrated bridge CE devices have, then sure, they could implement RA Guard.
But having your additional router sending RAs across the homenet might not be a particularly good idea anyway.
Sounds like you need to set it up as a NAT.

>>>> - arbitrary topology plug and play (homenet)
>>> 
>>> Yes, that’s homenet.   It would really help if folks who think homenet is done would try to deploy it in their home using OpenWRT and see how it goes.   Seriously.   This is not a solved problem.   We’re maybe 50-60% of the way there at this point.   I’ve been trying to make progress on this ever since HNCP was declared done, and occasionally get collaboration, and indeed we may be begining to make progress agan, but we could definitely use more participation if there are folks in 6man who want this to work and imagine that it already does.
>> 
>> The notion of "permissionless extensions of the network" is still somewhat unresolved. HNCP allows for that, but as we know it's not well supported/deployed. I had some hopes for multi-link subnet routing (implemented how it was originally intended, not as spanning tree in ND). But I have never gotten around to flesh that out in detail. Pascal has done various stuff in this space for lowpan, which may be something to build on.
>> 
>> The MLSR idea is basically a /64 shared across all links. Hosts register with routers using ARO (or DHCP). Routers advertise host routes in a routing protocol between themselves. The tricky parts are of course detecting when hosts go away, detecting movement and so on.
> 
> I’ve seen this.   It’s how the 6lowpan folks seem to have defined their “routing."   But scalability is horrible, and when I’ve looked at doing an implementation, it’s obviously ridiculously harder than just publishing an RA.   And it’s particularly hard if there’s no IPv6 on North Network.    So if there’s a way to get IPv6 to work in this case, that seems like a better option.

I wasn't thinking of doing it exactly like the 6lowpan does it.
Regardless I don't see why scaling should be problematic, are you planning to have millions of rapidly moving hosts on your shared /64 network?

>> A side meeting in Singapore perhaps?
> 
> I’m not going to be in Singapore—I just can’t justify the carbon footprint.   I do think we ought to have a deeper discussion about this, though.   Maybe a “virtual interim”?   If there’s interest, I’d be happy to organize this.   I’d also be happy to attend a side meeting in Singapore remotely, but our experience with that thus far has been pessimal, and I don’t think a fix is planned for Singapore (unless I just haven’t heard about it).


Cheers,
Ole