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 <[email protected]> On Behalf Of Michael Richardson > Sent: jeudi 4 juillet 2019 02:58 > To: [email protected]; V6 Ops List <[email protected]>; 6man <[email protected]> > Subject: Re: [6lo] ND cache entries creation on first-hop routers > > > Brian E Carpenter <[email protected]> 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 [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
