Hello Pascal,
I think that actually calling the 6BBRs to be an anycast group gets into
matters about anycast operation and security that would represent an
unnecessary burden. For one thing, we would need an anycast address for
the 6BBRs. RFC 7094 lays out some considerations for anycast and if we
wanted to go that way it would probably be appropriate to make a section
of the draft about it. Or, if you mean that every Registered Address
would appear to be an anycast address on the backbone, then that seems
to be a new use for anycast and might entail some unexpected consequences.
Regarding nearly simultaneous registrations from the same Registering
Node -- is this really a problem? If the 6LN sends out a NS and gets
multiple answers, the 6LN should just pick one of them, and not register
to all of them at the same time.
Regards,
Charlie P.
On 1/9/2019 10:51 PM, Pascal Thubert (pthubert) wrote:
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
