Re: [Iotops] Automatically connecting to stub networks...

[Ted Lemon <[e-mail]>]

“This” is what we did in the Apple thread border router. I’m nervous about anything in the IETF with IoT in the title because it will be subject to the Carsten Bormann DoS attack. 

I don’t know if we have visibility into the right part of Google to get the chrome problem fixed. Their IoT team is fairly far removed from their browser team. What’s the use case?

> On Dec 2, 2020, at 18:42, Michael Richardson <[e-mail]> wrote:
> 
> 
> Ted Lemon <[e-mail]> wrote:
>>> On Dec 2, 2020, at 16:16, Michael Richardson <[e-mail]>
>>> wrote:
>>> (trying to clean out my inbox)
>>> 
>>> Ted Lemon <[e-mail]> wrote:
>>>> I mentioned prior to IETF 107 that I wanted to start a conversation
>>>> about this problem, but didn’t have time to write a draft.  I’ve
>>>> written one, which I think describes my view of the problem pretty
>>>> well; I’d like to know if what I’ve written here makes sense to
>>>> others.
>>> 
>>> Ted, I think that your work addresses a problem space that is in some
>>> ways similar to the "share64" concept.  Not the same, but similar.
> 
>> Yes. But I think share64 on a WiFi network would require proxy ND,
>> which doesn’t scale well, particularly if you have multiple unmanaged
>> routers providing readability and transit.
> 
> I wasn't saying that the same solution applies, but rather the problem space
> is the same.   Device-X has some IPv6 on a network "behind" it, and wants to
> share addresses on a wifi/LAN in front of it in order to enable connectivity.
> 
> I'm unclear from reading your document if the RA's would have L=0 or L=1.
> 
>>> I think that the use of ULA which is advertise to the "LAN" for
>>> reachability does not have to be mutually exclusive with NAT64 for
>>> "cloud" reachability.
> 
>> Absolutely. That’s what we’re thinking for the ipv4 and dual stack
>> cases. Doesn’t work for v6-only.
> 
> So, if the LAN is v6-only and does not have DHCPv6-PD or HNCP+Babel, then I
> think it's a fail for cloud connectivity.   In particular, in this case, it's
> hard to report the failure to anyone offsite!
> 
> It might be worth describing how this failure case could be reported intelligently.
> This is an operational kind of thing which is in charter for IOTOPS.
> 
>>> Since your document does not actually require any new protocol, but
>>> just explains how to do something new using existing mechanism, I
>>> think that it would fit into the current IOTOPS charter.
> 
>> I don’t think this is IoT-specific. I would prefer to do the work in
>> intarea.
> 
> I don't think something needs to be IoT-only to belong in IOTOPS.
> 
>>> In answer to your question: State of the Art
>>> 
>>> Currently there is one known way to accomplish what we are describing
>>> here [[Michael, does ANIMA have a second way?]].
>>> 
>>> The ANIMA ACP sets up an overlay network with /128 routing via
>>> RPL(RFC6550) storing mode.
> 
>> I don’t get a mental picture from this of how it helps.
> 
> I'm sorry, I didn't finish the thought.  "It does not help at all"
> 
>> FWIW, Apple is now shipping a product (HomePod Mini) that does stub
>> network routing for thread networks, and there’s also an open source
>> implementation. Right now it only does the ULA solution. I’ll be
>> writing a draft that describes this soon.
> 
> I'm unclear what "this" is.
> 
> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [ 
>