Skip to main content

Stub Network Auto Configuration for IPv6
bofreq-lemon-stub-network-auto-configuration-for-ipv6-06

Document Type Approved BOF request
Title Stub Network Auto Configuration for IPv6
Last updated 2022-06-07
State Approved
Editor Ted Lemon
Responsible leadership Éric Vyncke
Additional resources Mailing List Archive
Mailing List
Send notices to (None)
bofreq-lemon-stub-network-auto-configuration-for-ipv6-06

Name: Stub Network Auto Configuration (SNAC) for IPv6

Description

We propose a working-group-forming BoF to work on the problem of connecting stub networks to existing infrastructure in the absence of an expert operator.

For many years the IETF has been working on the problem of constrained nodes and constrained networks. One challenge with constrained networks specifically is that they can't safely be bridged together with media that is less constrained because the constrained network, which typically will have a much lower data rate, will not be able to receive all the traffic that would be forwarded to it from the high-speed infrastructure network. To address this, constrained networks are generally treated as separate links from infrastructure networks.

In a managed network, constrained networks can be provisioned into the routing infrastructure. However, the vast majority of IPv6 links on the Internet are not managed, and so this approach leaves out most networks, specifically home and small office networks. This problem is described in detail in draft-lemon-stub-networks-ps, and a solution based on IPv6 routing and unicast DNS-SD is described in draft-lemon-stub-networks.

The motivation for having this BoF is that it's not entirely clear where in the IETF we should do this work; one option would be to form a working group. If that's the right approach, then we need to figure out what working group we are forming, and what its charter should be. Or, once we describe the set of work we want to do, we might conclude that there is already a working group in the IETF where we can do this work.

We would expect the scope of work to include:

  • How to connect a stub network to an infrastructure network that implements no new functionality we might define
  • New functionality we might define for improving connectivity/discoverability that would require support by some devices on the infrastructure network, e.g.
  • Support for automatically adding stub network DNS-SD service to an existing DNS-SD service provided by the infrastructure network
  • Support for automatically adding the stub network to the routing topology of the infrastructure network e.g. as is done for CE routers as a side effect of DHCPv6 prefix delegation

The current expectation is that a working group could produce a small set of documents describing how to use existing IETF specifications in order to accomplish the purpose of joining stub networks to existing infrastructure. To accomplish the goals listed under "new functionality" above, the working group may need to specify minor extensions to existing protocols; for example, DHCPv6 PD, when available, will work as-is to get a routable prefix for the stub network. DNS-SD is already working on specifications that can be used in stub networks, but a working group may need to specify how these DNS-SD specifications are used with stub networks.

Examples of existing IETF specifications that are expected to be needed for stub networks include:

  • RFC 4861 - Neighbor Discovery (provide IPv6 prefix where needed, provide route to stub network on infrastructure, etc.)
  • RFC 4193 - Unique Local addresses (provide IPv6 address space when there is no DHCPv6 service)
  • RFC 8766 - Provide service discovery for stub network services on infrastructure and vice versa
  • draft-ietf-dnssd-srp - Enable constrained clients to advertise services through stub router

Currently there is no anticipated need to produce entirely new protocols, or major protocol extensions, specifically for stub networks.

Required Details

Information for IAB/IESG

To allow evaluation of your proposal, please include the following items:

  • Any protocols or practices that already exist in this space:

The aforementioned stub network documents describe a solution that is currently being used in Thread networks. The IETF has standardized a solution based on proxy ND: https://datatracker.ietf.org/doc/html/rfc8929

  • Which (if any) modifications to existing protocols or practices are required:

The proposed solution is based on standard behaviors of existing protocols, as well as work that is nearing completion in the DNSSD working group. If a working group is formed, one of the stretch goals for the working group could be to define some new capabilities for home routers that would allow stub networks to be automatically integrated into the services provided by such a home router, e.g. the local DNS naming hierarchy, and the local routing infrastructure.

  • Which (if any) entirely new protocols or practices are required:

None.

  • Open source projects (if any) implementing this work:

The mDNSResponder and OpenThread projects currently contain implementations of the functionality we'd like to develop.

https://github.com/Abhayakara/mdnsresponder

https://github.com/openthread

Agenda

TBD, but should include:

  • Introduction
  • What we think might be in scope
  • Discussion: what should be in scope, what should be out of scope
  • Charter proposal discussion