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

[Toerless Eckert <[e-mail]>]

On Wed, Dec 02, 2020 at 06:47:38PM -0500, Ted Lemon wrote:
> ???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. 

Whow, i guess its christmas time, so you're trying to spread some love ?

What's a CBDA ? Is that a badge of honor to wear ? I have a Van-o-Gram from the
1990'th. Maybe i can upgrade by breast plating with a CBDA ? What do i need to do to get one ?

Back to business.  Some high level suggestions for your doc:

- Move your rants about HNCP to an appendix

- Maybe also the rant about service discovery being an integral part of the problem to an appendix.
  although i agree that a good part of the IETF community may not have gotten the message how it is,
  but its still disturbing the flow of reading when preaching to the choir like me.

- Put IPv6 into the title if all you care about is really only IPv6.
  Before this gets adopted by a WG, native support for also IPv4 should be a key scope discussion.
  Not everybody may have the same IP6 centric only business goal.
  (I Have No Opinion. Just saying).

- It would be nice to start section 2 with a description of a generic model
  without being specific to the protocol so one can check if/what protocol options
  do meet the model - as opposed to only the two ones you think are in your interest.

- For example: Why not simply start with DHCP-PD ? IMHO, every home router getting
  a prefix via DHCP-PD from a service provider is a provider of such a stub network.
  Of course, service discovery as you expect does usually not work in that environment,
  so that would need to be added.
  
- Would be lovely to detail exaple use-cases such as that Apple device (e.g.: in an appendix)
  to provide better motivation and also justification for the proposed protocol choices...


Cheers
    Toerless

> 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    [ 
> >    
> 
> -- 
> Iotops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iotops

-- 
---
[e-mail]