A new IETF WG has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs.
Stub Network Auto Configuration for IPv6 (snac) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Marc Blanchet <marc.blanc...@viagenie.ca> Kiran Makhijani <kiran.i...@gmail.com> Assigned Area Director: Éric Vyncke <evyn...@cisco.com> Internet Area Directors: Erik Kline <ek.i...@gmail.com> Éric Vyncke <evyn...@cisco.com> Mailing list: Address: s...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/snac Archive: https://mailarchive.ietf.org/arch/browse/snac/ Group page: https://datatracker.ietf.org/group/snac/ Charter: https://datatracker.ietf.org/doc/charter-ietf-snac/ Stub Network AutoConfiguration proposed charter A stub network is a network that can be connected to an existing infrastructure network and, to the extent possible, participate as part of that infrastructure. A stub network must be able to connect to an infrastructure network without modifications to that infrastructure network, even if MAC address lengths differ (e.g., IEEE 802.15.4). Hosts connected to the stub network should be able to do anything that hosts directly connected to the infrastructure network can do. Stub networks are leaf networks: they do not support the attachment of additional stub networks. The simplest use case for a stub network (e.g., a IEEE 802.15.4-based entertainment or lighting system) is to connect to an infrastructure network (e.g., a home network) that is a single layer-2 link (hence not running any routing protocol), without requiring any new behaviour from this infrastructure network. Hence, a solution that only provides transparent connectivity between the stub network and the infrastructure link to which it is directly connected is an important first step. Multiple distinct stub networks should be able to connect to the same infrastructure network. A more involved use case is to connect to an infrastructure network that can delegate an IPv6 prefix to the stub network and support unicast service discovery. The infrastructure network may be a single-link unmanaged network (e.g., a home network) or a managed multi-link network infrastructure. The multi-link use case may require the stub network prefix to be included in the routing plane of the infrastructure network. Both use cases are in scope for the working group. For all types of stub networks, the working group documents will allow IPv6-only stub networks to connect automatically to an infrastructure network, without any address translation (e.g., NPTv6 RFC 6296), so that hosts and services on the stub network can communicate as if they were connected directly to the infrastructure network. Hosts on the stub network(s) and the infrastructure network must be mutually discoverable, and mutually reachable. Discoverability refers to service discovery, e.g., DNSSD (RFC6763). In addition, hosts on the stub network should be able to connect to the Internet (via the infrastructure network), if desired, just as well as hosts on the infrastructure network are able to. The working group will coordinate with other relevant working groups, such as DNSSD or 6MAN or DHC, for any changes required in protocols and will make sure that those groups are included in major document reviews at appropriate times. Deliverables: * A framework document that explains how one or more stub routers connect one or more stub networks to a single unmanaged infrastructure link. This includes providing IP addresses required for communication, routes and routing required for communication, and providing service discovery for the stub network and the adjacent infrastructure link. * A document describing the set of services that must be provided by a multi-link infrastructure network in order for stub networks to be added to the infrastructure providing full mutual reachability, addressability, and discoverability between stub network hosts and hosts on adjacent and non-adjacent infrastructure links. This would address, for example, a building management network or an enterprise network. Milestones: Jan 2023 - Framework I-D adopted by the WG Jun 2023 - Services for multi-link adopted by the WG Nov 2023 - Framework I-D publication requested to the IESG Nov 2024 - Services for multi-link publication requested to the IESG _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
