Hello Pascal,
I think it's somewhat unusual to call something anycast and then not to
follow the recommended RFCs about how to manage anycast addresses. But
maybe it's O.K., who knows?
Regarding the matter with the 6LN choosing only one 6LR from possibly
several NAs, I thought that would resolve the matter about whether to
use the first primary, or the primary with the highest-address. Since
the latter seems to involve somewhat more signaling, I would prefer to
go with using the first primary.
Regards,
Charlie P.
On 1/11/2019 12:55 AM, Pascal Thubert (pthubert) wrote:
Hello Charlie
Please see below
-----Original Message-----
From: Charlie Perkins <[email protected]>
Sent: jeudi 10 janvier 2019 23:50
To: [email protected]
Cc: [email protected]
Subject: Re: [6lo] Link Local address and 6BBR
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.
[PT>] Well, my answer to you would be what you just said below. We call them
anycast and do nothing about it. It may be that more than one 6BBR answers? So
what ?
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.
[PT>] Exactly. Thus my conclusion to call that anycast and not do any
arbitration : )
For now I left the primary text in as is...
I'll send you a new update before the week end,
Pascal
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
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
