[If you see this a lot of times, I really apologize—I think it's relevant to all the mailing lists I'm sending it to, but I know that that's a lot. Please reply to s...@ietf.org, not here.]
You may have seen an announcement yesterday for the s...@ietf.org mailing list. The point of this mailing list is, first, to discuss the possible creation of a working group to work on specifications relating to the problem of stub networks, and secondly, assuming the working group forms, to do that actual work. The point of this work area is to make it possible to automatically attach a stub network (that is, an IPv6 network that does not provide transit) to existing infrastructure networks. So in a sense, you can think of this work as being largely about operational practices. However, because these practices need to be automatic (that is, we can't assume that the user knows how to set up a stub network), we need to document in some detail how stub network routers behave, so that we can get consistent, reliable automatic behavior. At present, the stub networks work relies on existing IPv6 protocols such as neighbor discovery to function. The goal of the Stub Network AutoConfiguration work is not to invent new protocol, but rather to say how to use existing protocols to accomplish the goal of automatically integrating stub networks into infrastructure. It's reasonable to expect that there might be some actual protocol extension work to do, but at least at present it doesn't look like there's a need to invent new protocols. An example of protocol extension work might be an extension to DHCPv6 prefix delegation to specifically support stub networks, or an extension to DNS-SD to support service discovery on stub networks. I'm not saying the working group would actually work on this sort of thing, but simply giving examples of the sort of thing the working group might find itself doing. Information about the SNAC BoF is available here: https://datatracker.ietf.org/doc/bofreq-lemon-stub-network-auto-configuration-for-ipv6/00/ There are several drafts available at that link that will give you a better idea of the problem. One key example where SNAC is useful is in the connection of constrained networks to infrastructure networks. E.g., an 802.15.4 mesh network like Thread. Existing products actually already do stub-network-like things, e.g. the Apple HomePod Mini and the most recent Apple TV. Because we are simply leveraging existing protocols, we didn't need to develop anything new in the IETF to do this, however it's our opinion that it would be useful for the IETF to think carefully about this problem and quite likely tweak the recommendations in the current stub network document. As an example, early on I added some code to do something called "vicarious router discovery," where if the stub router notices a device doing router discovery and doesn't see it succeed, it will reach out to that host. Not being an expert on ND or router discovery, I got this implementation quite wrong, and it didn't behave well. So when I say that the point of this working group is to work on this problem, I do not mean that the point is to get a rubber stamp on the existing solution. The point is rather to get real review of the work, fix any issues that are discovered, and do things differently if the way we are doing them now isn't ideal. FYI, I've set the reply-to on this email to the s...@ietf.org mailing list. If you really want to reply to all four mailing lists to which I've sent this, I can't stop you, but I would suggest that that might be taken poorly by the folks on those mailing lists, so please if possible join the s...@ietf.org mailing list before replying, and then I really look forward to the discussion. You can subscribe here: https://www.ietf.org/mailman/listinfo/snac Thanks! _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
