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

Michael,

On Wed, Dec 2, 2020 at 3:36 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> (trying to clean out my inbox)
>
> Ted Lemon <mellon@fugue.com> 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.
>
> 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.
>
> 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.
>

What is IOTOPS?

Behcet

>
> 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.
>
>     >
> 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  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>