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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 17 Feb 2020 15:21:46 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6lo-backbone-router-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this -- it was a good read.  I just have a few super-boring
poitns of apparent internal inconsistency to fix before publication.

There seems to be an internal inconsistency relating to the handling of
link-local addresses by a Bridging Proxy: Section 8 descriptively says
that such addresses are (always) registered ("[t]he Bridging Proxy
registers any Binding including for a Link-Local address to the 6LBR"),
but Section 9 has this behavior as optional ("[a] Bridging Proxy MAY
register Link Local addresses at the 6BBR and proxy ND for these
addresses over the backbone").

Similarly, I see Section 6 saying that when a 6BBR generates an NA in
response to an NS(DAD), it "MUST have the Override flag set", but
Section 9.2 says "MUST be answered ... the Override flag not set" (for
the "different registration" case, i.e., second bullet) and nothing at
all about the Override flag for the "not as fresh"/"Moved" case (i.e.,
the third bullet).  Am I misreading something?

Continuing the theme, Section 10 notes that a "Registering Node SHOULD
register all of its IPv6 Addresses to its 6LR, which is the 6BBR when
they are connected at Layer 2", but Appendix B states the stronger
condition that "[t]he 6BBR assumes that if a node registers at least one
IPv6 Address to it, then the node registers all of its Addresses to the
6BBR."

----------------------------------------------------------------------
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.

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?

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").

   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.)

   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.

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.

   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".

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.

Section 3

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

   *  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.

   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?

   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?

   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.

Section 3.1

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

   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).

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.

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?

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.

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?

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.

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).

   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.

   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?

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]".)

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]

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.

   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?

   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?

   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"?

   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/?

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.)

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")?

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 :)

   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"?

   The Registering Node SHOULD also follow [RFC7772] in order to limit

This is BCP 202, right?

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?

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!).

   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.

   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.

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

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?

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.)

Section 15

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

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.

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.

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., [...]"?

   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.

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.

   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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Feb 2020 16:25:48 +0000

Hello Benjamin

Again many thanks for your arch-fantastic reviews!

Let me handle the DISCUSS first and then I'll come back to you asap for the rest.

I published 17 since the proposed change had me take a global look at the proposed change vs. original ND.

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

> Thanks for this -- it was a good read.  I just have a few super-boring poitns of
> apparent internal inconsistency to fix before publication.
> 
> There seems to be an internal inconsistency relating to the handling of link-
> local addresses by a Bridging Proxy: Section 8 descriptively says that such
> addresses are (always) registered ("[t]he Bridging Proxy registers any Binding
> including for a Link-Local address to the 6LBR"), but Section 9 has this behavior
> as optional ("[a] Bridging Link Proxy MAY register Local addresses at the 6BBR
> and proxy ND for these addresses over the backbone").

For one thing the bridging proxy knows about LL addresses iff they are registered to it, which may only happen if the bridging proxy is the 6LR for the node, which is typical of hub and spoke (Wi-Fi) but not meshed wireless. In the Wi-Fi game you really want to extend the connectivity to the wireless guy, and that's possible because of the mac layer continuity (the AP is a L3 bridge). This text is already in a section that discusses the node being a 6LR so all I need to do s turn this into a SHOULD/MUST like this:
"
      A Bridging Proxy SHOULD register Link Local addresses at the 6BBR and
        MUST proxy ND for these addresses over the backbone.
"
The SHOULD is because the 6LBR on the backbone is optional and the proxy operation will work without it.

> 
> Similarly, I see Section 6 saying that when a 6BBR generates an NA in response
> to an NS(DAD), it "MUST have the Override flag set", but Section 9.2 says
> "MUST be answered ... the Override flag not set" (for the "different
> registration" case, i.e., second bullet) and nothing at all about the Override flag
> for the "not as fresh"/"Moved" case (i.e., the third bullet).  Am I misreading
> something?

The idea was that by default we follow https://tools.ietf.org/html/rfc4861#section-7.2.8, and a proxy does not set the override 'O' flag because we do not want to alter a cache and we want the real owner to win if present on link. Note that this only applies to multicast NS (Lookup and DAD) since a NUD (which is unicast) indicates that the asker has this node in his cache. So the NUD can have the 'O' flag set even as a proxy; it does not matter. We can have text to say that that does not really help.

Also, we should not even have uppercase text, it's all inherited from IPv6 ND.

We may set the 'O' flag to take over the NCEs in nodes on the backbone when a registering node moves from a 6BBR to another. This is done to save polling traffic from nodes on the backbone. The Mobile IPv6 (RFC 6275) already sets the 'O' flag for mobile registrations. That's OK if the owner can never connect directly to the backbone.

The exception we wanted to add is that if the incoming NS(DAD) has an EARO that denotes an older or a duplicate registration then we can set the 'O' flag. But that does not really make a difference. 

In contradiction to RFC 4862 we want to answer even in tentative state when we have the additional knowledge that the remote is also a proxy with an older state. This is done so that the old 6BBR knows where the new 6BBR is so it can redirect packets. Because the remote uses the EARO we know it will find the Status that's returned, so it really doesn't matter if we set the 'O' flag as well. 

RFC 4862 section 5.4.4 on DAD indicates that a legacy node does not care whether the 'O' flag is set when doing DAD (IOW the address is in tentative state) so things will work with the 'O' flag unset.

Section 9. is where the normative text is and this creates confusion and as you found, discrepancies. 
I'd rather retell the basics in section 6. and point on section 9. for the normative behavior. 

So for section 6 we'd get:

"    IPv6 ND operates as follows on the backbone:

   *  Section 7.2.8 of [RFC4861] specifies that an NA message generated
      as a proxy does not have the Override flag set in order to ensure
      that if the real owner is present on the link, its own NA will
      take precedence, and that this NA does not update the NCE for the
      real owner if one exists.

   *  A node that receives multiple NA messages updates an existing NCE
      only if the Override flag is set; otherwise the node will probe
      the cached address.

   *  When an NS(DAD) is received for a tentative address, which means
      that 2 nodes form the same address at nearly the same time,
      section 5.4.3 of [RFC4862] cannot sort out the first come and the
      address is abandoned.

   *  In any fashion, [RFC4862] indicates that a node never responds to
      a Neighbor Solicitation for a tentative address.

   This specification adds information about proxied addresses that
   helps sort out a duplication (different ROVR) from a movement (same
   ROVR, different TID), and in the latter case the older registration
   from the fresher one (by comparing TIDs).

   When a Registering Node moves from one 6BBR to the next, the new 6BBR
   sends NA messages to update the NCE in node over the backbone.  The
   6BBR may set the Override flag in the NA messages if it is known that
   the Registering Node will not connect directly to the backbone (e.g.,
   the Registering Node is attached using a different type of
   interface).

   A node that supports this specification and that receives multiple NA
   messages with an EARO option and the same ROVR MUST favor the NA with
   the freshest EARO over the others.

   When the Binding is in Tentative state:

   *  an NS(DAD) that indicates a duplication can still not be asserted
      for first come, but the situation can be avoided using a 6LBR on
      the backbone that will serialize the order of appearance of the
      address and ensure first-come/first-serve.

   *  an NS or an NA that denotes an older registration for the same
      Registered Node is not interpreted as a duplication as specified
      in section 5.4.3 and 5.4.4 of [RFC4862], respectively.

   When the Binding is no more in Tentative state:

   *  an NS or an NA with an EARO that denotes a duplicate registration
      (different ROVR) is answered with an NA message that carries an
      EARO with a status of 1 (Duplicate), unless the received message
      is an NA that carries an EARO with a status of 1.

   In any state:

   *  an NS or an NA with an EARO that denotes an older registration
      (same ROVR) is answered with an NA message that carries an EARO
      with a status of 3 (Moved) to ensure that the stale state is
      removed rapidly.

   This behavior is specified in more details in Section 9.
"

In 9.1 (Binding in Tentative state)
 
"
The Tentative state covers a DAD period over the backbone during
   which an address being registered is checked for duplication using
   procedures defined in [RFC4862].

   For a Binding in Tentative state:

   *  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 that indicates an existing registration owned by a different
      Registering Node (different ROVR).  An NA MUST be sent back to the
      Registering Node with a status of 1 (Duplicate).  This behavior
      might be overridden 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]).

   *  The Binding MUST be removed if an NS(DAD) message is received over
      the Backbone for the Registered Address with no EARO, or
      containing an EARO with a different ROVR that indicates a
      tentative registration by a different Registering Node.  In that
      case, an NA MUST be sent back to the Registering Node with a
      status of 1 (Duplicate).  This behavior might be overridden 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]).

   *  The Binding MUST be removed if an NA or an NS(DAD) message is
      received over the Backbone for the Registered Address containing
      an EARO with a that indicates a fresher registration ([RFC8505])
      for the same Registering Node (same ROVR).  A status of 3 is
      returned in the NA(EARO) back to the Registering Node.

   *  The Binding MUST be kept unchanged if an NA or an NS(DAD)
      message is received over the Backbone for the Registered Address
      containing an EARO  that indicates an older registration
      ([RFC8505]) for the same Registering Node (same ROVR).  The
      message SHOULD be answered with an NA that carries an EARO with a
      status of 3 (Moved) and the Override flag not set.  This behavior
      might be overridden by policy, in particular if the registration is
      not trusted.

   *  Other NS(DAD) and NA messages from the Backbone are ignored.

"

> register all of its IPv6 Addresses to its 6LR, which is the 6BBR when they are
> connected at Layer 2", but Appendix B states the stronger condition that "[t]he
> 6BBR assumes that if a node registers at least one
> IPv6 Address to it, then the node registers all of its Addresses to the 6BBR."

Made it a MUST

Please let me know if that works for you;

I'll handle the rest of your reviews and the others as soon as I can, I have limited access during my vacations.

Take care,

Pascal

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 20 Feb 2020 16:15:36 -0800

Hi Pascal,

> Let me handle the DISCUSS first and then I'll come back to you asap for the rest.

Sorry to make you interrupt your holiday!

> The SHOULD is because the 6LBR on the backbone is optional and the proxy operation will work without it.

I think I'm confused about how this proposal fits in to the changes in the
-17, though what's in the -17 itself does look like it resolves the
inconsistency.

> Also, we should not even have uppercase text, it's all inherited from IPv6 ND.

Good point!

>       section 5.4.3 of [RFC4862] cannot sort out the first come and the

(Perhaps a bit more wordsmithing to do on this one re "cannot detect which
node first claimed the address")

>       a Neighbor Solicitation for a tentative address.

maybe s/fashion/case/?  Or just "In all cases".

>    sends NA messages to update the NCE in node over the backbone.  The

nit: "nodes" (and maybe "on" vs. "over", or "NA messages over the backbone
to update [...]"?)

>    the Registering Node is attached using a different type of

[obligatory "how would the 6BBR know that?"]

>    When the Binding is no more in Tentative state:

"no longer", I think.

>    This behavior is specified in more details in Section 9.

s/details/detail/ (this is a weird quirk of English).

>       Registering Node with a status of 1 (Duplicate).  This behavior

I'd suggest adding "to indicate that the binding has been
[removed|rejected]".  (My adversarial parser is claiming that "NA MUST be
sent back" could be misread to apply always, not just when a qualifying NA
message was received.)  Though prepending  "In that case" as is done in the
next bullet would work, too, and has the benefit of being consistent
between items.

>       an EARO with a that indicates a fresher registration ([RFC8505])

Don't we have to assume that an NA/NS(DAD) with no EARO is fresher than the
local registration?

>       might be overridden by policy, in particular if the registration is

(I assume it's the local registration that's "not trusted", here.  It's
probably clear enough as-is, with no change needed.)

> Please let me know if that works for you;

That works for me, yes.

> I'll handle the rest of your reviews and the others as soon as I can, I have limited access during my vacations.

Please enjoy your vacation!  I will still be here when you get back.

-Ben