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 a knowledgable 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 it will create flow control problems. 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 goal of this BoF is to figure out where in the IETF to do this work. There doesn't seem to be a good match: v6ops isn't entirely right because it's an ops working group; 6man doesn't really make sense either. Intarea is to general, and unlikely to attract focus. Homenet is being closed, and isn't solving quite the same problem anyway. So one obvious option would be to form a working group that can focus on this specific problem and serve as a place where the work can be finished.

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

Fill in the details below. Keep items in the order they appear here.

Required Details

• Status: WG Forming
• Responsible AD: Eric Vyncke
• BOF proponents: Ted Lemon <mellon@fugue.com>, Stuart Cheshire <cheshire@apple.com>
• BOF chairs: TBD
• Number of people expected to attend: 50
• Length of session (1 or 2 hours): 2 hours
• Conflicts (whole Areas and/or WGs)
• Chair Conflicts: TBD
• Technology Overlap: TBD
• Key Participant Conflict: 6man, dnsop, dnssd

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

Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

• Mailing List: TBD
• Draft charter: TBD
• Relevant drafts:
  • Problem Statement:
    • https://datatracker.ietf.org/doc/draft-lemon-stub-networks-ps/
  • Solutions
    • https://datatracker.ietf.org/doc/draft-lemon-stub-networks/