Hello Charlie When a node registers to multiple 6BBR the registered address is really like an anycast address on the backbone. Anycast handling is a bit under-specified in ND in general. And this is not the place to solve that problem, thus our current discussion.
Note that first registration as you proposed is a bit hard to achieve. A node may move and register to more than one 6BBR at roughly the same instant. The TID will be the same. A race condition where the NS(DAD) cross on the backbone is likely and creates an anycast situation anyway. When present the 6LBR on the backbone may sort it out but the protocol elements for that resolution are missing. My suggestion is to mention that one can register to more than one 6BBR and that the address is to be treated as an anycast address on the backbone, the exact details out of scope - removing the concept of primary which would be a welcome simplification for the IESG review. The caveat is that the NA(EARO) will have to carry the real information as opposed to being obfuscated, to the different 6LBRs can recognize parallel registrations and ignore the conflict. Does that work for you ? Pascal > Le 10 janv. 2019 à 07:33, Pascal Thubert (pthubert) <[email protected]> a > écrit : > > Hello Michael > > I agree with the simplest, and I’m happy with the resolution to say that link > local can be proxied in bridging mode but the scope for uniqueness is the > collection of links covered by the 6LBR. > > I also agree that it is not necessarily the most common configuration but it > appears to be needed for some .11 configurations. > > All the best! > > Pascal > >> Le 9 janv. 2019 à 20:27, Michael Richardson <[email protected]> a écrit : >> >> >> Pascal Thubert (pthubert) <[email protected]> wrote: >>> But doing so, we bar Link Local traffic that could have happened >>> between nodes attached to different 6BBRs, e.g., in a Wi-Fi environment >>> where the 6BBRs can be collocated with APs and maybe operating as >>> Bridging Proxies. The proposal on the table is thus to proxy ND for >>> Link Local addresses in the case of a bridging proxy. The registration >>> and proxy operation would be the same as for a Global Address, but >>> there’s at least one caveat. >> >> LL traffic is likely mDNS traffic and/or DNS-SD traffic. >> I don't think it's useful to pretend it's a single subnet for the purposes >> of making that work. >> >>> * Make the scope of uniqueness for a Link Local Address the collection >>> of links covered by a 6LBR (easy, no change in the spec) >> >> seems simplest. >> >>> What do people think? >> >> I think it's too much thinking. >> >> -- >> Michael Richardson <[email protected]>, Sandelman Software Works >> -= IPv6 IoT consulting =- _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
