Skip to main content

Stub Network Auto Configuration for IPv6 (snac)

WG Name Stub Network Auto Configuration for IPv6
Acronym snac
Area Internet Area (int)
State Active
Charter charter-ietf-snac-01 Approved
Document dependencies
Additional resources GitHub Organization
Zulip stream
Personnel Chairs Darren Dukes, Kiran Makhijani
Area Director Éric Vyncke
Mailing list Address
To subscribe
Chat Room address

Charter for Working Group

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.


  • 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.


Date Milestone Associated documents
Nov 2024 Services for multi-link publication requested to the IESG
Nov 2023 Framework I-D publication requested to the IESG
Jun 2023 Services for multi-link adopted by the WG
Jan 2023 Framework I-D adopted by the WG