Re: Automatically connecting to stub networks...

[Ted Lemon <[e-mail]>]

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

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

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

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. 

Thanks for the review and comments!

> 
>> https://www.ietf.org/internet-drafts/draft-lemon-stub-networks-ps-00.txt
> 
>> Abstract: IETF currently provides protocols for automatically
>> connecting single hosts to existing network infrastructure.  This
>> document describes a related problem: the problem of connecting a stub
>> network (a collection of hosts behind a router) automatically to
>> existing network infrastructure in the same manner.
> 
> Your criticism if HNCP is all true, but an important part is that it really
> only provides for allocation of prefixes; not routing.
> (I still think that the WG made a mistake not extending OSPFv3)
> HNCP is not the part that's missing: it's the routing protocol in the home
> that is what's needed to do something more complicated.
> 
> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [ 
>    
> 
>