Hello Kyle Many thanks for your review! Let's see below: > I see no specifically transport-related issues in this draft, but I note a few nits > as well as unaddressed issues raised by RFC 4903. > > Potential issues: The draft addresses ND, DAD, and to some extent link-scoped > multicast and broadcast (sections 2.3 and 2.4 of 4903), but does not address > either the IP Model (section 2.1) or hop limit issue (2.2). > 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/ > 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
