[homenet] FW: [Snac] WG Review: Stub Network Auto Configuration for IPv6 (snac)

["Eric Vyncke (evyncke)" <[e-mail]>]

As this is the follow-up of Ted Lemon's work on 'stub neworks' in the Homenet WG, you may find useful to review this proposed WG charter.

-éric

On 10/09/2022, 07:01, "The IESG" <[e-mail]> wrote:


    A new IETF WG has been proposed in the Internet Area. The IESG has not made
    any determination yet. The following draft charter was submitted, and is
    provided for informational purposes only. Please send your comments to the
    IESG mailing list ([e-mail]) by 2022-09-19.

    Stub Network Auto Configuration for IPv6 (snac)
    -----------------------------------------------------------------------
    Current status: Proposed WG

    Chairs:
      Marc Blanchet <[e-mail]>
      Kiran Makhijani <[e-mail]>

    Assigned Area Director:
      Éric Vyncke <[e-mail]>

    Internet Area Directors:
      Erik Kline <[e-mail]>
      Éric Vyncke <[e-mail]>

    Mailing list:
      Address: [e-mail]
      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 goal of the working group is to allow
    IPv6-only stub networks to connect automatically to an infrastructure
    network, 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