[6lo] Advocating a generalisation of RFC8505 to non-6lo LANs

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Brian:

Yes, I'm willing to make the case. 

There are a number of reasons to enable a registration method on beyond 6lo networks:
- It is useful in wireless in general because it addresses non-transit multipoint links (see https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/) and NBMA ML-subnets
- it is useful in particular in Wi-Fi because it reduces the need for broadcast quite dramatically.
- It is useful in a switched fabric to maintain an accurate state in the overlay mapping server (see https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/)
- It is useful in a situation of host mobility in general, (see the discussion in https://tools.ietf.org/html/draft-ietf-rift-rift-06#section-5.3.3 ) 
- It is useful for routers with hardware assist forwarding to avoid the punting dance and dropping of packets
- It provides SAVI properties with a workable Secure ND (see https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/)
- It provides an abstract interface to the router to get routing services (already used with RIFT, RPL, see https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/, and ND proxy, see https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/)
- It solves a number of problems including Jen's, but also sleeping devices on non-6lo networks, remote DOS against router and ND cache, and more.

All in all I see it as a much needed modernization of ND to cope with the evolutions of the network (IOT, Wi-Fi and overlays) and with the new needs and behaviors (instant connectivity, fast roaming).

All the best,

Pascal

> -----Original Message-----
> From: 6lo <[e-mail]> On Behalf Of Michael Richardson
> Sent: jeudi 4 juillet 2019 02:58
> To: [e-mail]; V6 Ops List <[e-mail]>; 6man <[e-mail]>
> Subject: Re: [6lo] ND cache entries creation on first-hop routers
> 
> 
> Brian E Carpenter <[e-mail]> wrote:
>     >> I’m interested to have a parallel discussion on where RFC 8505 can not
>     >> apply. In the products and use cases I’m aware of, it could, since we
>     >> are actually faking it by snooping ND and DHCP to achieve similar but
>     >> less accurate results.
> 
>     > So if you are advocating a generalisation of RFC8505 to non-6lo LANs,
>     > that's certainly a discussion we could have, IMHO.
> 
> I think that it could be applied in situations of servers, such as data centers
> where there are multiple tenants. (Many VM infrastructures have shared
> front-end networks)
> 
> I think that temporary addressess are not a feature in some of those
> deployments that everyone wants, and thus having a registration system is a
> feature.
> 
> This does not solve the smartphone on new WIFI issue, which is a different
> situation completely.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [