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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Jan 2019 17:47:38 +0000

Dear all :

We are ready to publish draft 10 for the backbone router and ask for WGLC, but for one pending issue that was raised during the internal review between authors on the 6BBR draft.

The initial intention was not to cover Link Local addresses at all, since the multilink subnet is made of different links and the 6BBR is a L3 box that isolates them. This is true for a routing proxy, but not exactly right for a bridging proxy, which is really a layer-3 switch with MAC layer bridging continuity on the data path.

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.

Consider the flow in https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-09#section-3.1. The EDAR/EDAC exchange with the 6LBR would contain the Link Local address as opposed to a Global Address, but the EDAR/ EDAC does not give an indication of a link ID. If the 6LBR is on-link then that's not an issue but if we place it farther away, we could detect collision that would be a false positive for link local addresses used in different MLSNs served by a same 6LBR.

There are a number of possibilities to solve this:

  *   A new ND option in the DAR/DAC to indicate a Link ID (complex to specify, setup and deploy)
  *   Make the scope of uniqueness for a Link Local Address the collection of links covered by a 6LBR (easy, no change in the spec)
  *   Indicate the MLSN prefix (e.g., in the source address of the EDAR) and make that MLSN the scope of uniqueness for a Link Local Address (must force the 6BBR to source the DAR with an address in the subnet)

What do people think?

Pascal

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 9 Jan 2019 10:58:03 -0800

Hello folks,

I think that the first 6BBR to create the Binding Cache entry for a 
Registered Address should be the primary 6BBR for that address. This is 
in contrast to the current specification, which says that the 6BBR with 
the highest IP address should be the primary.  I think that this could 
lead to some bit of confusion or at least extra protocol actions, if a 
new 6BBR with a higher address would try to take over the role of the 
primary 6BBR.

Please take a look and consider which algorithm (first versus 
highest-addressable BBR) you think is preferable.

Regards,
Charlie P.

On 1/9/2019 9:47 AM, Pascal Thubert (pthubert) wrote:
>
> Dear all :
>
> We are ready to publish draft 10 for the backbone router and ask for 
> WGLC, but for one pending issue that was raised during the internal 
> review between authors on the 6BBR draft.
>
> The initial intention was not to cover Link Local addresses at all, 
> since the multilink subnet is made of different links and the 6BBR is 
> a L3 box that isolates them. This is true for a routing proxy, but not 
> exactly right for a bridging proxy, which is really a layer-3 switch 
> with MAC layer bridging continuity on the data path.
>
> 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.
>
> Consider the flow in 
> https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-09#section-3.1. 
> The EDAR/EDAC exchange with the 6LBR would contain the Link Local 
> address as opposed to a Global Address, but the EDAR/ EDAC does not 
> give an indication of a link ID. If the 6LBR is on-link then that’s 
> not an issue but if we place it farther away, we could detect 
> collision that would be a false positive for link local addresses used 
> in different MLSNs served by a same 6LBR.
>
>   * Make the scope of uniqueness for a Link Local Address the
>     collection of links covered by a 6LBR (easy, no change in the spec)
>   * Indicate the MLSN prefix (e.g., in the source address of the EDAR)
>     and make that MLSN the scope of uniqueness for a Link Local
>     Address (must force the 6BBR to source the DAR with an address in
>     the subnet)
>
> What do people think?
>
> Pascal
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Jan 2019 14:26:56 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > 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-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Jan 2019 06:33:16 +0000

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-masked]> a écrit :
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Jan 2019 06:51:37 +0000

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-masked]> a écrit :
> 
> Hello Michael 
>

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 10 Jan 2019 14:49:43 -0800

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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Jan 2019 08:55:31 +0000

Hello Charlie

Please see below

> -----Original Message-----
> From: Charlie Perkins <[email-masked]>
> Sent: jeudi 10 janvier 2019 23:50
> To: [email-masked]
> Cc: [email-masked]
> 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

> > 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
> >
> >> 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
> >>
> >>>> 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.
> >>> I don't think it's useful to pretend it's a single subnet for the
> >>> purposes of making that work.
> >>>

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 11 Jan 2019 06:34:53 -0800

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:
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo