Let's try this again. On Fri, Feb 7, 2020 at 5:48 AM Pascal Thubert (pthubert) <[email protected]> wrote:
> > "Currently, IPv6 continues the IPv4 model in that a subnet prefix is > > associated with one link." > > True, but that's not a world premiere either. All the route-over LLNs that > are deployed (that's millions of RFC 6550 nodes) defeat that definition, > since with or without a federating backbones, a LLN is already a MLSN. > None of the previous route-over work RFCs claims to extend RFC 4291. We > could here but to what avail? > Note that I do not mind either way. > If you find the time, maybe you'd be interested in reading / commenting > the subnet-related discussions in > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ Ah, ok. I figured this was a new property provided by 6lo backbone routers, mostly based on a quick reading of 6550 and failure to find "multi-link" or "subnet" references that went anywhere. If this property has already achieved rough consensus for 6lo applications, I'm happy to leave it at that. > 6lo traffic is not specific. It is IPv6. There is no special rights or > format, though the packets may progress slowly, and be compressed or > fragmented. > Well, that makes it not IPv6 in the strictest sense, right? Implemented in the mesh-under network, you couldn't simply dump the tiny fragments onto a non-6lo network and expect a node to reassemble them, could you? But this is a bit of a diversion, and falls under the same rough consensus category (IMO) as the multi-link subnet issue. > But you're correct; link scope and HL=1 packets don't reach the entire > subnet. > This is actually the desired behavior to protect the wireless medium, in > particular against broadcasts induced by the reactive ND operations. > Stipulated. I agree this is a desirable property. > Proposal to augment the paragraph in the introduction that discusses MLSN > as follows > " > > This specification defines the 6BBR as a Routing Registrar [RFC8505] > that provides proxy services for IPv6 Neighbor Discovery. As > represented in Figure 1, Backbone Routers federate multiple LLNs over > a Backbone Link to form a MultiLink Subnet (MLSN). The MLSN breaks > the Layer-2 continuity and splits the broadcast domain, in a fashion > that each Link, including the backbone, is its own broadcast domain. > This means that devices that rely on a link-scope multicast on the > backbone will only reach other nodes on the backbone but not LLN > nodes. The same goes a packet that is sent with a hop limit of 1 or > using a Link-Local destination address. This packet may reach other > nodes on the backbone but not LLN Nodes. In order to enable the > continuity of IPv6 ND operations beyond the backbone, and enable > communication using Global or Unique Local Addresses between any node > in the MLSN, Backbone Routers placed along the LLN edge of the > Backbone handle IPv6 ND on behalf of Registered Nodes and forward > IPv6 packets back and forth. > This might be a bit much. I think what would suffice is a sentence simply mentioning that "A key property of MultiLink subnets is that link-local traffic 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." > > Nit: This text is confusing: > > > > Either respond using NA messages as a proxy or bridge as a unicast > > frame the IPv6 ND messages (multicast DAD and Address Lookup, and > > unicast NUD) received for the Registered Address over the > > Backbone. > > > > In particular, I'm struggling with what the second option here is. Is it > that a > > 6BBR could bridge incoming ND messages to other links? Is it an option > in lieu > > of the first, or are NA messages always to be proxied and all other > messages to > > be bridged? > > Yes, this text is really unclear, sorry for that. Proposal to clarify as > follows: > > " > > The 6BBR may respond immediately as a Proxy in lieu of the > Registering Node, e.g., if the Registering Node has a sleeping > cycle that the 6BBR does not want to interrupt, and if the 6BR has > a recent state that is deemed fresh enough to permit the proxied > response. It is preferred, though, that the 6BBR checks whether > the Registering Node is still responsive on the Registered > Address. to that effect: > > * as a Bridging Proxy, the 6BBR forwards a multicast DAD or an > Address Lookup message as a unicast MAC-Layer frame to the SLLA > of the Registering Node that matches the Target in the ND > message, and forwards as is the unicast NUD, so as to let the > Registering Node answer with the ND Message and options that it > sees fit; > > * as a Routing Proxy, the 6BBR checks the liveliness of the > Registering Node, e.g., using a NUD verification, before > answering on its behalf. > " > Looks good, modulo some minor editorial nits. Hopefully this resolves everything. Thanks, Kyle
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
