On Fri, Feb 7, 2020 at 5:48 AM Pascal Thubert (pthubert) <[email protected]> wrote:
> > For the first, does the > > presumption that a multi-link subnet exists as a recognized and > supportable > > network configuration require update of RFC 4291, which AFAICT is still > > authoritative for the statement that: > > > > "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 backbone routers, mostly based on a > > > > > For the second, since I'm assuming something called a "router" will in > fact > > decrement the hop limit when forwarding a packet (I couldn't find the > answer > > in a brief perusal of the references that seemed relevant), for > completeness it > > might be helpful to mention something about how multicast traffic e.g. > with > > hop limit 1 will not successfully transit to hosts in the same subnet > but on a > > different link. In general, making clear that the issues raised in 4903 > are > > systematically addressed with respect to the unique requirements of 6lo > traffic > > would be useful to the reader. > > 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. > 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. > > 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. > > " > > > > > 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. > " > > > > > > Nit: Please use a single form to specify a multi-link subnet: I see > "MultiLink" > > and "Multi-Link" used in different places. > > Done : ) > > Pleas let me know if the above fits your expectations. I plan to publish > soon, incorporating nits from Elwyn Davies. > > Many thanks again, Kyle! > > Pascal > >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
