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" <iesg-secret...@ietf.org> 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 (i...@ietf.org) by 2022-09-19.
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 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
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
