This is all very right, Carsten.
> RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty much a > no-brainer, if that foo has points where the 6LBR functionality is naturally > centralized. No brainer it is, but for Lorenzo's issues on state preservation or reconstruction upon router reboot. > Not so easy for brownfield, i.e., in networks where classic ND is already > used in > some hosts and some routers. “Efficient ND” (which was essentially RFC 6775 > for Ethernet and thus also traditional Wi-Fi) mostly didn’t take off at the > time > because we didn’t articulate a cohabitation (“transition”) strategy. I’m sure > we can do that if we put a little more focus on it, leading to another > specification that describes how to run in mixed classic/efficient ND > networks. For I started that at 6lo and there is text in https://datatracker.ietf.org/doc/html/draft-ietf-6lo-backbone-router , e.g., in section 3.2. The coexistence is also discussed in https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup but at some point it is not a 6lo problem anymore and that work should really move somewhere else. Being non-maintenance, it seems too early for 6MAN. If so maybe we should form a short-lived WG to sort out the issues raised by Lorenzo, yours (coexistence) and mine (limit use of broadcast / interface with a fabric mapping server and do unicast lookup when possible). All the best, Pascal > -----Original Message----- > From: Carsten Bormann <[email protected]> > Sent: jeudi 4 juillet 2019 13:22 > To: Pascal Thubert (pthubert) <[email protected]> > Cc: Michael Richardson <[email protected]>; [email protected]; V6 Ops List > <[email protected]>; 6man <[email protected]> > Subject: Re: [6lo] Advocating a generalisation of RFC8505 to non-6lo LANs > > RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty much a > no-brainer, if that foo has points where the 6LBR functionality is naturally > centralized. > > Not so easy for brownfield, i.e., in networks where classic ND is already > used in > some hosts and some routers. “Efficient ND” (which was essentially RFC 6775 > for Ethernet and thus also traditional WiFi) mostly didn’t take off at the > time > because we didn’t articulate a cohabitation (“transition”) strategy. I’m sure > we can do that if we put a little more focus on it, leading to another > specification that describes how to run in mixed classic/efficient ND > networks. > > Grüße, Carsten > > > > On Jul 4, 2019, at 12:28, Pascal Thubert (pthubert) <[email protected]> > wrote: > > > > 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 > > > > _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
