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