Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-backbone-router-16: (with DISCUSS and COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Benjamin

Again and again, many thanks for your arch-fantastic reviews!

Continuing:

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In Section 3 we talk about the Binding Table as a "distributed database", but I
> didn't see much further exposition on that topic.  It would be great to have a
> bit of discussion about what the logical contents of a row in the database are
> (e.g., IP address, MAC address, ROVR, registration state, associated host route,
> ...), as well as what the concurrency and consistency properties of the
> distributed database are expected or required to be.

Yes there's quite a lot of stuff in there when you look at the code.  
The piece of interest for the "distributed database" is what this specification synchronizes between 6BBRs over the backbone so I suggest to keep it at that high level info, ignoring, e.g., the host route reference in a routing proxy.

"
  Each Backbone Router (6BBR) maintains a data structure for its
   Registered Addresses called a Binding Table.  The abstract data that
   is stored in the Binding Table includes the Registered Address,
   anchor information on the Registering Node such as connecting
   interface, Link-Local Address and Link-Layer Address of the
   Registering Node on that interface, the EARO including ROVR and TID,
   a state that can be either REACHABLE, TENTATIVE, or STALE, and other
   information such as a trust level that may be configured, e.g., to
   protect a server.  The combined Binding Tables of all the 6BBRs on a
   backbone form a distributed database of 6LNs that reside in the LLNs
   or on the IPv6 Backbone.
"

> 
> I also am not quite sure I understand the full picture for backwards
> compatibility/incremental deployment: it seems like we may need the
> 6LBR(s) to be updated to support this spec before anything else can use it,
> though I'm not sure.  For example, if we need both IPv6 ND's DAD and
> EDAR/EDAC between 6BBR/6LBR, does that mean the 6LBR has to be updated
> first?

There was no 6LBR before 6LoWPAN ND, and no 6BBR before this. RFC 8505 covers the legacy 6LBRs, and the text there applies.

What's new is that we allow placing the 6LBR on the backbone where it can see classical ND for the same subnet as the LLN's, and how that interacts with the 6LBR normal activity of EDAR/EDAC. That collision could not happen before, there was no classical ND on the LLN, and a remote 6LBR would be on a different subnet. So we had to specify a new beast, a 6LBR that can reside on the backbone, and how it plays with classical ND. So I do not see a for backwards compatibility/incremental deployment issue with the 6LBR on the backbone, it's a new beast, there was none before.


> 
> Section 1
> 
>    Because IPv6 ND messages sent to the SNMA group are broadcast at the
>    radio MAC Layer, wireless nodes that do not belong to the SNMA group
>    still have to keep their radio turned on to listen to multicast NS
>    messages, which is a total waste of energy for them.  In order to
> 
> nit: "total waste" might be a stronger statement than you want to have to
> defend (vs. just "waste").

done

> 
>    These problems can be alleviated by reducing the IPv6 ND broadcasts
>    over wireless access links.  This has been done by splitting the
>    broadcast domains and routes between subnets, or even by assigning a
>    /64 prefix to each wireless node (see [RFC8273]).
> 
> "If there are already solutions, why do we need more solutions?" ;) (Maybe it's
> worth mentioning that these proposed workarounds have weaknesses, or even
> what those weaknesses are.)

Slippery slope since there are proponents and use cases for each solution.
What about adding:
"
    But deploying a single large subnet can still be attractive to avoid
    renumbering in situations that involve large numbers of devices and mobility
    within a bounded area.

"

> 
>    Another way is to proxy at the boundary of the wired and wireless
>    domains the Layer 3 protocols that rely on MAC Layer broadcast
>    operations.  For instance, IEEE 802.11 [IEEEstd80211] situates proxy-
>    ARP (IPv4) and proxy-ND (IPv6) functions at the Access Points (APs).
>    The 6BBR provides a proxy-ND function and can be extended for proxy-
>    ARP in a continuation specification.
> 
> nit-ish: it might be worth saying something about "in an analogous manner"
> and/or "for LLNs" in the last sentence.

There is an analogy between the L2 bridging at the AP and the L3 routing proxy.
But here we are talking about implementing a .11 requirement, so far missing from the IETF side for IPv6.
802.11 in this sentence is considered a LLN.

"
   A way to reduce the propagation of IPv6 ND broadcast in the wireless
   domain while preserving a large single subnet is to form a Multi-Link
   Subnet (MLSN).  Each Link in the MLSN, including the backbone, is its
   own broadcast domain.  A key property of MLSNs is that link-local
   unicast traffic, link-scope multicast, and traffic with a hop limit
   of 1 will not transit to nodes in the same subnet on a different
   link, something that may produce unexpected behavior in software that
   expects a subnet to be entirely contained within a single link.

   This specification considers a special type of MLSN with a central
   backbone that federates edge (LLN) links, each Link providing its own
   protection against rogue access and tempering or replaying packets.
   In that particular topology, ND proxies can be placed at the boundary
   of the edge links and the backbone to handle IPv6 ND on behalf of
   Registered Nodes and forward IPv6 packets back and forth.  The ND
   proxy enables the continuity of IPv6 ND operations beyond the
   backbone, and enables communication using Global or Unique Local
   Addresses between any pair of nodes in the MLSN.

   The 6LoWPAN Backbone Router (6BBR) is a Routing Registrar [RFC8505]
   that provides proxy-ND services.  A 6BBR acting as a Bridging Proxy
   provides a proxy-ND function with Layer-2 continuity and can be
   collocated with a Wi-Fi Access Point (AP) as prescribed by IEEE Std
   802.11 [IEEEstd80211].  A 6BBR acting as a Routing Proxy is
   applicable to any type of LLN, including LLNs that cannot be bridged
   onto the backbone, such as IEEE Std 802.15.4 [IEEEstd802154].
"
> 
> Section 2.2
> 
>    Sleeping Proxy:  A 6BBR acts as a Sleeping Proxy if it answers ND
>       Neighbor Solicitations over the Backbone on behalf of the
>       Registering Node which might be in a sleep state in a low power
>       network.  The Sleeping Proxy that is also a Bridging Proxy will
>       preferably forward the relevant messages to the Registering Node
>       as unicast frames in accord to the duty cycle of the Registering
>       Node and let it respond.
> 
> Should we expect the reader to know what "the relevant messages" are that
> the bridging proxy forwards to the registering node?  Without additional
> context, the text here implies that the ND NS messages are the "relevant"
> ones, with the awkward implication that the 6BBR both answers on behalf of
> the registering node and forwards messages to it.

Makes sense; what about:
"
   Sleeping Proxy:  A 6BBR acts as a Sleeping Proxy if it answers IPv6
      ND Neighbor Solicitations over the Backbone on behalf of the
      Registering Node that is in a sleep state and cannot answer in
      due time

"
I moved the text on bridging proxy to the bridging proxy definition, see below.

> 
>    Bridging Proxy:  A Bridging Proxy provides IPv6 ND proxy functions
>       while preserving forwarding continuity at the MAC Layer.  The
>       Bridging Proxy advertises the MAC Address of the Registering Node
>       as the TLLA in the proxied NAs over the Backbone.  In that case,
>       the MAC Address and the mobility of 6LN is still visible across
>       the bridged Backbone, and the 6BBR may be configured to proxy for
>       Link Local Addresses.
> 
> nit: I think there's a singular/plural issue for "mobility of 6LN".

"
Bridging Proxy:  A Bridging Proxy provides IPv6 ND proxy functions
      while preserving forwarding continuity at the MAC Layer.  In that
      case, the MAC Address and the mobility of the Registering Node is
      visible across the bridged Backbone.  The Bridging Proxy
      advertises the MAC Address of the Registering Node as the TLLA in
      the proxied NAs over the Backbone, and proxies ND for all unicast
      addresses including Link-Local Addresses.  Instead of replying on
      behalf of the Registering Node, a Bridging Proxy will preferably
      forward the NS Lookup and NUD messages that target the Registered
      Address to the Registering Node as unicast frames and let it
      respond in its own. 
"


> 
> Section 2.4
> 
> nit: the current structure doesn't do a good job of indicating why the
> references are grouped into bullet points as opposed to a single consolidated
> list.

Making it look like
"

   Classical IPv6 ND:  "Neighbor Discovery for IP version 6" [RFC4861],
      "IPv6 Stateless Address Autoconfiguration" [RFC4862] and
      "Optimistic Duplicate Address Detection" [RFC4429],

   IPv6 ND over multiple links:  "Neighbor Discovery Proxies (proxy-ND)"
      [RFC4389] and "Multi-Link Subnet Issues" [RFC4903],

   6LoWPAN:  "Problem Statement and Requirements for IPv6 over Low-Power
      Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], and

   6LoWPAN ND:  Neighbor Discovery Optimization for Low-Power and Lossy
      Networks [RFC6775] and "Registration Extensions for 6LoWPAN
      Neighbor Discovery" [RFC8505].
"

> 
> Section 3
> 
> nit: the list after figure 1 is missing a blank line between the last two elements.

The desired effect was a nested list, inner compact;

"

   *  Multi-Link-subnet functions (provided by the 6BBR on the backbone)
      performed on behalf of registered 6LNs, and

   *  Routing registrar services that reduce multicast within the LLN:

      -  Binding Table management
      -  failover, e.g., due to mobility

"

> 
>    *  Advertise a Registered Address over the Backbone using an
>       unsolicited NA message, asynchronously or as a response to a NS
>       message.  This includes joining the multicast group associated to
> 
> nit: I think the binding of "unsolicited" is not quite right, as it currently also
> applies to the "as a response to a NS" case.

"
Advertise a Registered Address over the Backbone using an NA message,
        either unsolicited or as a response to a NS message

"

> 
>    The first of these functions enables the 6BBR to fulfill its role as
>    a Routing Registrar for each of its attached LLNs.  The remaining
>    functions fulfill the role of the 6BBRs as the border routers
>    connecting the Multi-link IPv6 subnet to the Internet.
> 
> I'm a bit confused by this last sentence (probably just me, but...) -- the
> functions in question are things like forwarding/briding traffic between LLN
> and backbone, so why is "the Internet" required to be in play?

Yes, misleading though ultimately the 6BBRs provide global reachability whenever possible.
What about

"
	The first of these functions enables the 6BBR to fulfill its
	role as a Routing Registrar for each of its attached LLNs.
	The remaining functions fulfill the role of the 6BBRs as the
	border routers that federate the Multi-link IPv6 subnet.
"


> 
>    The registration to a proxy service uses an NS/NA(EARO) exchange.
> 
> nit(?): does the "(EARO)" apply to just NA, or to NS as well?
Both. Does this work:
"
The registration to a proxy service uses an NS/NA exchange with EARO.
"

> 
>    The 6BBRs use the Extended Address Registration Option (EARO) defined
>    in [RFC8505] as follows:
>       [...]
>    *  The Link Layer Address (LLA) that the 6BBR advertises for the
>       Registered Address on behalf of the Registered Node over the
>       Backbone can belong to the Registering Node; in that case, the
>       6BBR (acting as a Bridging Proxy (see Section 8)) bridges the
>       unicast packets.  Alternatively, the LLA can be that of the 6BBR
>       on the Backbone interface, in which case the 6BBR (acting as a
>       Routing Proxy(see Section 7)) receives the unicast packets at
>       Layer 3 and routes over.
> 
> I'm not seeing how the EARO is used as part of this.

Yes, changed the intro to
"
	The 6BBRs performs IPv6 ND functions over the backbone as follows:
"

> Section 3.1
> 
> Would it be worth a forward-reference to Section 9 (for it's list of "6LR
> operation is modified as follows")?

"
   This specification adds the EARO as a possible option in RS, NS(DAD)
   and NA messages over the backbone.  This document specifies the use
   of those ND messages by 6BBRs over the backbone, at a high level in
   Section 6 and in more detail in Section 9.

"


> 
>    Note: [RFC6775] requires that the registration NS(EARO) contains an
>    SLLAO and [RFC4862] that the NS(DAD) is sent from the unspecified
> 
> nit: RFC 6775 predates RFC 8505 that introduces the EARO, so it's hard to see
> how 6775 specifically requires this of a registration NS(EARO).

RFC 6775 introduced the ARO with a must of SLAAO. RFC 8505 defines the EARO that extends the EARO and inherits from it.
But there was redundant text. Now fixed to:
"

   Note: [RFC8505] requires that the registration NS(EARO) contains an
   Source Link Layer Address Option (SLLAO).  [RFC4862] requires that
   the NS(DAD) is sent from the unspecified address for which there
   cannot be a SLLAO.  Consequently, an NS(DAD) cannot be confused with
   a registration.

"


> 
> Section 3.3
> 
> side note: some of our previous discussions on 6lo documents gave me the
> impression that a 6LBR was more of a privileged/distinguished thing than
> Figure 4 makes it out to be, e.g., that there would be one logical 6LBR per
> network.  Going back and re-reading (e.g., RFC 8505) it seems I was mistaken,
> and it's okay to have many independent 6LBRs like this; they just need to be
> managing distinct LLNs.

We seem to have the same conception of 6LBR as a privileged/distinguished thing. 
Note that it can be implemented as a hierarchy of servers. In the picture you see a 6LBR per LLN that ensures that the addresses are not duplicated locally. When the 6LBR proxy registers to the 6BBR, the 6BBR tells the 6LBR on the backbone to ensure the global uniqueness.
We missed the real integration of RPL and ND, ideally the RPL root would do the proxy registration and we could live with just one 6LBR on the backbone too. But it is hard to design between groups, even harder between areas.


> 
> Section 3.4
> 
>    *  Identical registrations (same TID, same ROVR) from the same
>       Registering Node are accepted with a status of 0 (Success).  In
>       Tentative state, the response is held and may be overwritten, but
> 
> nit: is this still "the EDAC response" as in the previous item?

Here we are in the 6BBR that receives a registration NS(EARO) and answers an NA(EARO).

Proposal to change the first sentence to:
"
   Addresses in an LLN that are reachable from the Backbone by way of
   the 6BBR function must be registered to that 6BBR, using an NS(EARO)
   with the R flag set [RFC8505].  The 6BBR answers with an NA(EARO) and
   maintains a state for the registration in an abstract Binding Table. 
"



> 
> Section 3.5
> 
>    A 6BBR may optionally be primary or secondary.  The primary is the
> 
> I'm not sure what the "optionally" means here -- is it an implementation choice
> to just not think about the question of primary vs. secondary and alawys
> behave the same [as primary]?  The next paragraph implies that it is so, but
> perhaps more clarity is warranted.

Replaced  "optionally" with "either"


> 
> Section 4
> 
>    Nodes located inside the subnet do not perform the IPv6 Path MTU
>    Discovery [RFC8201].  [...]
> 
> nit(?): I couldn't find where in RFC 8201 it's specified that PMTUD is not
> performed for same-subnet paths; is that specified elsewhere or just a
> consequence of the nature of a subnet?

The MTU is a property of the link (see RFC 4861). Long as the subnet is within a Link (be it transit) the MTU is a constant.
Implementations of ND over the backbone do not know better and expect that situation so for them same subnet = same MTU. This we have to ensure that the MTU is the same across the whole MLSN.

"

   Legacy nodes located on the backbone expect that the subnet is
   deployed within a single link and that there is a common Maximum
   Transmission Unit (MTU) for intra-subnet communication, the Link MTU.
   They will not perform the IPv6 Path MTU Discovery [RFC8201] for a
   destination within the subnet.  For that reason, the MTU MUST have
   the same value on the Backbone and all federated LLNs in the MLSN.

"


> 
> Section 5
> 
>    This specification allows for an address to be registered to more
>    than one 6BBR.  Consequently a 6LBR MUST be capable of maintaining
>    state for each of the 6BBR having registered with the same TID and
>    same ROVR.
> 
> This seems like something worth calling out in the "Updating RFC 6775"
> section.

So the end of 3.1 becomes

"
   This specification allows to deploy a 6LBR on the backbone where EDAR
   and EDAC messages coexist with classical ND.  It also adds the
   capability to insert IPv6 ND options in the EDAR and EDAC messages.
   A 6BBR acting as a 6LR for the Registered Address can insert an SLLAO
   in the EDAR to the 6LBR in order to avoid a Lookup back.  This
   enables the 6LBR to store the MAC address associated to the
   Registered Address on a Link and to serve as a mapping server as
   described in [I-D.thubert-6lo-unicast-lookup].

   This specification allows for an address to be registered to more
   than one 6BBR.  Consequently a 6LBR that is deployed on the backbone
   MUST be capable of maintaining state for each of the 6BBR having
   registered with the same TID and same ROVR.

"
> 
> Section 6
> 
>    The 6BBR advertises and defends the Registered Addresses over the
>    Backbone Link using RS, NS(DAD) and NA messages with the Registered
>    Address as the Source or Target address, respectively.
> 
> nit: I don't think "respectively" is right, since there are three elements in the
> first list (RS, NS(DAD), and NA) but only two in the second (Source address,
> Target address).

Removed "respectively". 
What goes where is fully specified in IPv6 ND, no need to restate it.

> 
>    An NA message generated in response to an NS(DAD) MUST have the
>    Override flag set and a status of 1 (Duplicate) or 3 (Moved) in the
>    EARO.  An NA message generated in response to an NS(Lookup) or an
>    NS(NUD) MUST NOT have the Override flag set.
> 
> I think there's an implicit "by the 6BBR" in both the "message generated"s
> here, but please confirm.

Confirmed. This text is gone per the resolution of the DISCUSS.
Added " the 6BBR acts as follows" in several places of the new text.

> 
>    This specification enables proxy operation for the IPv6 ND resolution
>    of LLN devices and a prefix that is used across a Multi-Link Subnet
>    MAY be advertised as on-link over the Backbone.  This is done for
>    backward compatibility with existing IPv6 hosts by setting the L flag
>    in the Prefix Information Option (PIO) of RA messages [RFC4861].
> 
> Are there any drawbacks to providing this backwards-compatible behavior
> worth mentioning?

"on-link" the most common way. It's possible that some nodes do not support anything else on ethernet.
So the idea is we have to support it but we do not require it.



> Section 7
> 
>    EUI-48).  Since a 6LN may not be able to resolve an arbitrary
>    destination in the MLSN directly, the MLSN prefix MUST NOT be
>    advertised as on-link in RA messages sent towards the LLN.
> 
> nit(?): is there a single distinguished MLSN prefix to merit the definite article
> here?  (I note that in the previous section we speak only of "a prefix that is
> used across a [MLSN]".)

The latter, I'll use your wording.


> Section 8
> 
>    If the Registering Node owns the Registered Address, then its
>    mobility does not impact existing NCEs over the Backbone.  Otherwise,
>    when the 6LN selects another Registering Node, the new Registering
>    Node SHOULD send a multicast NA with the Override flag set to fix the
>    existing NCEs across the Backbone.
> 
> I think I'm confused about the distinction between "Registering Node"
> and "6LN", here -- in my head they are the same entity.  (If I replace
> "Registering Node" with "6BBR" in the second and third occurrences, things
> seem to make more sense and are roughly analogous to the discussion in
> Section 7...but looks can be deceiving.) [ed. Section 10 does describe a case
> where Registering Node and 6LN are different]

Actually it's already in section 3.3.

Let me use Fig 5 as reference. I hope you have a fixed font : )

6LoWPAN Node        6LR             6LBR            6BBR
       (mesh leaf)     (mesh router)   (mesh root)
            |               |               |               |
            |  6LoWPAN ND   |6LoWPAN ND     | 6LoWPAN ND    | IPv6 ND
            |   LLN link    |Route-Over mesh|Ethernet/serial| Backbone
            |               |               |/Internal call |
            |  IPv6 ND RS   |               |               |
            |-------------->|               |               |
            |----------->   |               |               |
            |------------------>            |               |
            |  IPv6 ND RA   |               |               |
            |<--------------|               |               |
            |               |               |               |
            |  NS(EARO)     |               |               |
            |-------------->|               |               |
            | 6LoWPAN ND    | Extended DAR  |               |
            |               |-------------->|               |
            |               |               |  NS(EARO)     |
            |               |               |-------------->|
            |               |               |  (proxied)    | NS-DAD
            |               |               |               |------>
            |               |               |               | (EARO)
            |               |               |               |
            |               |               |  NA(EARO)     |<timeout>
            |               |               |<--------------|
            |               | Extended DAC  |               |
            |               |<--------------|               |
            |  NA(EARO)     |               |               |
            |<--------------|               |               |


The 6LN is on the left, it is the owner of the address and registers to a 6LR one hop away.
The 6LBR does EDAR to a 6LBR at the top of the graph, multiple hops away, usually the mesh root (e.g., RPL root).
The 6LBR will do a proxy registration to the 6BBR for all the nodes in the mesh that is attached to it. By that I mean register on behalf. The 6LBR is the registering node. It hides the complexity of the mesh from the 6BBR.
The 6BBR does proxy ND, it hides the complexity of the rest of the subnet from to the 6LBR.

 The text before fig 5 can be improved as
 "
   Figure 5 illustrates IPv6 signaling that enables a 6LN (the
   Registered Node) to form a Global or a Unique-Local Address and
   register it to the 6LBR that serves its LLN using [RFC8505] using a
   neighboring 6LR as relay.  The 6LBR (the Registering Node) then
   proxies the [RFC8505] registration to the 6BBR to obtain proxy-ND
   services from the 6BBR.

   The RS sent initially by the 6LN is a transmitted as a multicast and
   contained within 1-hop broadcast range where hopefully a 6LR is
   found.  The 6LR is expected to be already connected to the LLN and
   capable to reach the 6LBR, possibly multiple hops away, using unicast
   messages.
"

What I can do it go through the spec and see when to change 6LN to "registering node" or "registered node".

Also I can improve the intro to:
"   
   Knowledge of which address to proxy for can be obtained by snooping
   the IPV6 ND protocol (see [I-D.bi-savi-wlan]), but it has been found
   to be unreliable.  An IPv6 address may not be discovered immediately
   due to a packet loss, or if a "silent" node is not currently using
   one of its addresses.  A change of state (e.g., due to movement) may
   be missed or misordered, leading to unreliable connectivity and
   incomplete knowledge of the state of the network.

  With this specification, the address to be proxied is signaled
   explicitly through a registration process.  A 6LoWPAN node (6LN)
   registers all its IPv6 Addresses using NS messages with an Extended
   Address Registration Option (EARO) as specified in [RFC8505] to a
   6LoWPAN Router (6LR) to which it is directly attached.  If the 6LR is
   a 6BBR then the 6LN is both the Registered Node and the Registering
   Node.  If not, then the 6LoWPAN Border Router (6LBR) that serves the
   LLN proxies the registration to the 6BBR.  In that case, the 6LN is
   the Registered Node and the 6LBR is the Registering Node.  The 6BBR
   performs IPv6 Neighbor Discovery (IPv6 ND) operations on its Backbone
   interface on behalf of the 6LNs that have registered addresses on its
   LLN interfaces without the need of a broadcast over the wireless
   medium.
"
 



> Section 9
> 
>    even for a duplicate address.  Consequently, and unless
>    administratively overridden, the 6BBR still needs to perform IPv6 ND
>    DAD over the backbone after an EDAC with a status code of 0 or 9.
> 
> I'd be curious to see a pointer to the discussions that caused "unless
> administratively overridden" to be introduced, as naively that note does not
> seem necessary.

The idea behind it is that if all nodes register to the 6LBR then the DAD can be avoided.
But the only way to know is administrative. I wanted to leave that door open. But I guess it is implicitly.
Removed the text.

> 
>    If a registration is received for an existing Binding with a non-null
>    Registration Lifetime and the registration is fresher (same ROVR,
>    fresher TID), then the Binding is updated, with the new Registration
>    Lifetime, TID, and possibly Registering Node.  In Tentative state
>    (see Section 9.1), the current DAD operation continues unaltered.  In
>    other states (see Section 9.2 and Section 9.3 ), the Binding is
>    placed in Reachable state for the Registration Lifetime, and the 6BBR
>    returns an NA(EARO) to the Registering Node with a status of 0
>    (Success).
> 
> Does this mean we don't re-do DAD for registrations already in a Stale state
> when we receive an updated registration for them?

Correct. If a sign of reuse of the address had been seen the Binding would have been removed in 9.3. That's the point actually of keeping the address in Stale state.

> 
>    Upon a registration that is identical (same ROVR, TID, and
>    Registering Node), the 6BBR returns an NA(EARO) back to the
>    Registering Node with a status of 0 (Success).  A registration that
>    is not as fresh (same ROVR, older TID) is ignored.
> 
> What (if anything) happens to the registration lifetime in this case?

Clarifying to
"
   Upon a registration that is identical (same ROVR, TID, and
   Registering Node), the 6BBR does not alter its current state.  In
   Reachable State it returns an NA(EARO) back to the Registering Node
   with a status of 0 (Success).  A registration that is not as fresh
   (same ROVR, older TID) is ignored.
"


> 
>    registering node.  It MAY preserve a temporary state in order to
>    forward packets in flight.  The state may be a NCE formed based on a
>    received NA message, or a Binding in Stale state and pointing at the
>    new 6BBR on the backbone.
> 
> nit: is this an exhaustive list of permitted ways to implement "temporary
> state"?

I guess not, but those are the 2 that make the most sense.
That text corresponds to a old BBR when a new one shows up, not to a state being removed.
"

   The old 6BBR removes its Binding Table entry and notifies the
   Registering Node with a status of 3 (Moved) if a new 6BBR claims a
   fresher registration (same ROVR, fresher TID) for the same address.
   The old 6BBR MAY preserve a temporary state in order to forward
   packets in flight.  The state may for instance be a NCE formed based
   on a received NA message.  It may also be a Binding Table entry in
   Stale state and pointing at the new 6BBR on the backbone, or any
   other abstract cache entry that can be used to resolve the Link-
   Layer Address of the new 6BBR.  The old 6BBR SHOULD also use REDIRECT
   messages as specified in [RFC4861] to update the correspondents for
   the Registered Address, pointing to the new 6BBR. 
"


> 
>    The implementation should also use REDIRECT messages as specified in
>    [RFC4861] to update the correspondents for the Registered Address,
>    pointing the new 6BBR.
> 
> s/should/SHOULD/?

Yes, already done

> Section 9.1
> 
>    *  The Binding MUST be removed if an NA message is received over the
>       Backbone for the Registered Address with no EARO, or containing an
>       EARO with a status of 1 (Duplicate) that indicates an existing
>       registration owned by a different Registering Node.  In that case,
>       an NA MUST be sent back to the Registering Node with a status of 1
>       (Duplicate) in the EARO.  This behavior might be overriden by
>       policy, in particular if the registration is trusted, e.g., based
>       on the validation of the ROVR field (see [I-D.ietf-6lo-ap-nd]).
> 
> I suggest to reword this to say "an NA is sent back to the Registering Node" to
> avoid having a normative "MUST" that is then overridden by the last sentence.
> (Similarly for the next item as well.)

done

> 
> Also, to check my understanding, the first two bullets in combination mean
> that if we somehow end up in a state with identical Tentative bindings at two
> different 6BBRs, they will both respond to each others'
> NS(DAD) with an NA, causing both bindings to be removed (i.e., "everyone
> loses")?

Yes that is the spirit of RFC 4861. They lose only if the ROVR is different.

> 
> Section 10
> 
>    The Registering Node may be the 6LN owning the IPv6 Address, or a
>    6LBR that performs the registration on its behalf in a Route-Over
>    mesh.
> 
> Having this earlier would probably have saved me some confusion :)

Yes I changed the intro as discussed above


> 
>    The Registering Node SHOULD register all of its IPv6 Addresses to its
>    6LR, which is the 6BBR when they are connected at Layer 2.  Failure
>    to register an address may result in the address being unreachable by
>    other parties if the 6BBR cancels the NS(Lookup) over the LLN or to
>    selected LLN nodes that are known to register their addresses.
> 
> I'm not sure I'm parsing the second sentence correctly -- what's the antecedent
> for "or to selected LLN nodes"?

That's the canceling thing. A 6BBR may turn a multicast lookup from the backbone into a series of unicast mac frames, but unicast only to nodes that do not play the registration game since it knows all the addresses of the nodes that do.

"
   The Registering Node MUST register all of its IPv6 Addresses to its
   6LR, which is the 6BBR when they are connected at Layer 2.  Failure
   to register an address may result in the address being unreachable by
   other parties if the 6BBR cancels the NS(Lookup) over the LLN or to
   selected LLN nodes that are known to register their addresses.

"


>    The Registering Node SHOULD also follow [RFC7772] in order to limit
> 
> This is BCP 202, right?

It is. Added it.

> 
> Section 11
> 
> We force a sequencing that has EDAR/EDAC occur before normal NS(DAD);
> does this provide a new DoS avenue by virtue of delaying the normal NS(DAD)
> procedure by (e.g.) dropping the EDAC messages?

Arguably the DAD is so overly long (1 second is a long time and there can be retries) that the additional wait is negligible.
Dropping the EDAC is difficult for an attacker  since the 6BBR and the 6LBR are interconnected by the backbone.
No I do not see that. 

> 
> It might be worth a brief preface that since we're modifying the ND and DAD
> processes, the attacks in scope are basically limited to blocking discovery of
> taking over addresses from other nodes (which, to be fair, can in some cases
> have substantial consequences in terms of reading the "stolen" traffic!).

Argl, I cannot parse that. Would you kindly suggest text?

> 
>    This specification applies to LLNs and a backbone in which the
>    individual links are protected against rogue access, e.g., by
>    authenticating a node that attaches to the network and encrypting at
>    the MAC layer the transmissions that may be overheard.  In
>    particular, the LLN MAC is required to provide secure unicast to/from
>    the Backbone Router and secure Broadcast from the Backbone Router in
>    a way that prevents tampering with or replaying the RA messages.
> 
> It seems like it would be worth stating these requirements/applicability
> statement much earlier in the document (possibly in addition to here), e.g., in
> the Introduction.

Done in
"
   This specification considers a special type of MLSN with a central
   backbone that federates edge (LLN) links, each Link providing its own
   protection against rogue access and tempering or replaying packets.
"
Already quoted above

> 
>    provide the proof-of-ownership.  A possible attack over the backbone
>    can be done by sending an NS with an EARO and expecting the NA(EARO)
>    back to contain the TID and ROVR fields of the existing state.  With
>    that information, the attacker can easily increase the TID and take
>    over the Binding.
> 
> The 6BBR can also perform such an attack, right?  It might be worth explicitly
> stating that we trust it to behave honestly in order for this stuff to work
> properly.

Sure, the attacker impersonates a 6BBR. A compromised 6BBR is an ideal attacker.
A compromised 6BBR can do anything like accept registration but not forward traffic, not proxy, etc...
But that's obvious isn't it?

> 
> We could also discuss how things break if the "distributed database" of
> registrations gets out of sync across 6BBRs/etc..

The Stale entry will eventually time out. Any fresher sign of life will kill it. We have text that makes the source of the lookup prefer a fresher response. Not sure what to say.

> How do things degrade if a secondary 6BBR "stands back" to let a primary
> handle a given message but the primary 6BBR has gone offline unbeknownst to
> the secondary?
> 

Let me think all this and the ones before through and update separately. 

> Are there any noteworthy scaling requirements to the bridging and routing
> proxy modes?  (I don't think so, and we just allude to "dimensioned for the
> number of registrations that each needs to support"
> in Appendix B, but it doesn't hurt to ask.)

Nothing that strikes me.

> 
> Section 15
> 
> RFC 6550 is only mentioned once, as a "non-normative example", so seems
> more appropriately placed in the Informative References.

Done

> 
> Section 16
> 
> It might be worth replacing RFC 6830 with draft-ietf-lisp-rfc6830bis, which is
> both significantly different from RFC 6830 and fairly close to done.

Yes but we do not need to understand the details of the protocol for that informational ref.
It's just listed as an example.

> 
> We have "SHOULD [...] support Packet-Loss Resiliency for Router Solicitations
> [RFC7559]" which, per
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-
> references/
> would put it in the Normative References.  Likewise for RFC 7772.

Done, The latter is only a BCP, so it will be a missref.

> Appendix A
> 
>    By default the specification does not have a trust model, e.g.,
>    whereby nodes that associate their address with a proof-of-ownership
>    [I-D.ietf-6lo-ap-nd] should be more trusted than nodes that do not.
>    Such a trust model and related signaling could be added in the future
>    to override the default operation and favor trusted nodes.
> 
> Well, we kind of have a trust model: "anyone on the backbone and anyone that
> can authenticate to the LLN MAC is trusted equally; others are not trusted".  So
> perhaps it's more appropriate to go with "does not have a fine-grained trust
> model: all nodes that can authenticate to the LLN MAC or attach to the
> backbone are equally trusted.  It would be desirable to provide a stronger
> authorization model, e.g., [...]"?

Applied
"
   By default the specification does not have a fine-grained trust
   model: all nodes that can authenticate to the LLN MAC or attach to
   the backbone are equally trusted.  It would be desirable to provide a
   stronger authorization model, e.g., whereby nodes that associate
   their address with a proof-of-ownership [I-D.ietf-6lo-ap-nd] should
   be more trusted than nodes that do not.  Such a trust model and
   related signaling could be added in the future to override the
   default operation and favor trusted nodes.
"


> 
>    Future documents may extend this specification by allowing the 6BBR
>    to redistribute Host routes in routing protocols that would operate
>    over the Backbone, or in MIPv6, or FMIP, or the Locator/ID Separation
> 
> Is there a reference for FMIP?  We don't mention it elsewhere in the document,
> as we do for MIPv6.

Added informational ref to RFC 5568

> 
> Appendix B
> 
> We seem to cover the requirements from Appendix B of RFC 8505 out of
> order: B.3, B.1, B.4, B.6, then B.2.  I didn't think very hard about whether
> there's good rhetorical reason for the current order, though.

Not much but I do not feel it's worth acting upon (and it's late)

> 
>    The impact if the IPv6 ND operation is limited to one of the
>    federated LLNs, enabling the number of 6LNs to grow.  The Routing
> 
> nit: I don't think this is a well-formed sentence.  Possibly it's just suffering from
> a typo (s/if/of/), though I'm not entirely sure.

What about

"
The negative impact of the IPv6 ND-related broadcasts can be
limited to one of the federated links, enabling the number of 6LNs 
to grow.
"

That's a lot!

A susual I published -18 with the above to help you validate.

https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-backbone-router-18

Again, many many thanks Benjamin!

Pascal