Re: [6lo] Link Local address and 6BBR

[Charlie Perkins <[e-mail]>]

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) <[e-mail]> 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 <[e-mail]> a écrit :
>>>
>>>
>>> Pascal Thubert (pthubert) <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
>>> -= IPv6 IoT consulting =-