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

[Benjamin Kaduk <[e-mail]>]

Hi Pascal,


On Thu, Feb 20, 2020 at 04:25:48PM +0000, Pascal Thubert (pthubert) wrote:
> 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.

Sorry to make you interrupt your holiday!

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

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.

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

Good point!

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

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

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

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

>    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

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

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

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

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

"no longer", I think.

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

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

> 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

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.

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

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

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

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

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

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