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

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

"

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

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