Concluded WG Light-Weight Implementation Guidance (lwig)
Note: The data for concluded WGs is occasionally incorrect.
WG | Name | Light-Weight Implementation Guidance | |
---|---|---|---|
Acronym | lwig | ||
Area | Internet Area (int) | ||
State | Concluded | ||
Charter | charter-ietf-lwig-02 Approved | ||
Document dependencies | |||
Additional resources | Issue tracker, Wiki, Zulip Stream | ||
Personnel | Chairs | Mohit Sethi, Zhen Cao | |
Area Director | Erik Kline | ||
Mailing list | Address | lwip@ietf.org | |
To subscribe | https://www.ietf.org/mailman/listinfo/lwip | ||
Archive | https://mailarchive.ietf.org/arch/browse/lwip/ |
Closing note for Working Group
LWIG is now closed. The one working group document (draft-ietf-lwig-curve-representations) will become AD-sponsored but retain its current datatracker state. Any significant discussion about this document will find a suitable forum, if needed. The working group mailing list will remain open, but discussion is recommended to move to other fora, such as IOTOPS WG (iotops@ietf.org). Thanks to all who participated, contributed text, and chaired.Final Charter for Working Group
Communications technology is being embedded into our environment.
Different types of devices in our buildings, vehicles, equipment and
other objects have a need to communicate. It is expected that most of
these devices will employ the Internet Protocol suite. However, there is
a lot of variation in the capabilities between different types of
devices, and it is not always easy to embed all the necessary features.
The Light-Weight Implementation Guidance (LWIG) Working Group focuses on
helping the implementors of the smallest devices. The goal is to be able
to build minimal yet interoperable IP-capable devices for the most
constrained environments.
Building a small implementation does not have to be hard. Many small
devices use stripped down versions of general purpose operating systems
and their TCP/IP stacks. However, there are implementations that go even
further in minimization and can exist in as few as a couple of kilobytes
of code, as on some devices this level of optimization is necessary.
Technical and cost considerations may limit the computing power, battery
capacity, available memory, or communications bandwidth that can be
provided. To overcome these limitations the implementors have to employ
the right hardware and software mechanisms. For instance, certain types
of memory management or even fixed memory allocation may be required. It
is also useful to understand what is necessary from the point of view of
the communications protocols and the application employing them. For
instance, a device that only acts as a client or only requires one
connection can simplify its TCP implementation.
The purpose of the LWIG working group is to collect experiences from
implementors of IP stacks in constrained devices. The
group shall focus only on techniques that have been used in actual
implementations and do not impact interoperability with other devices.
The techniques shall also not affect conformance to the relevant
specifications. The output of this work is a document that describes
implementation techniques for reducing complexity, memory footprint, or
power usage. The topics for this working group will be chosen from these
protocols: IPv4, IPv6, UDP, TCP, ICMPv4/v6, MLD/IGMP, ND, DNS,
DHCPv4/v6, IPsec, 6LOWPAN, COAP, RPL, SNMP and NETCONF protocols. This
document will be helpful for the implementors of new devices or for the
implementors of new general-purpose small IP stacks. It is also expected
that the document increases our knowledge of what existing small
implementations do, and helps in the further optimization of the
existing implementations. On areas where the considerations for small
implementations have already been documented the group shall make an
effort to refer to those documents instead of developing its own.
Generic hardware design advice and software implementation techniques
are outside the scope of this work, as such expertise is not within the
IETF domain. Protocol implementation experience, however, is within the
IETF domain. The group shall also not develop any new protocols or
protocol behavior modifications beyond what is already allowed by
existing RFCs, because it is important to ensure that different types of
devices can work together. The group shall not develop assumptions or
profiles about the operating environment of the devices, because, in
general, it is not possible to guarantee any special configuration.
Finally, while implementation techniques relating to security mechanisms
are within scope, mere removal of security functionality from a protocol
is not an acceptable recommendation.
Given that the group works on both IP and transport layer protocols it
is necessary to ensure that expertise in both aspects is present in the
group. Participation from the implementors of existing small IP stacks
is also required.
Milestones
Date | Milestone | Associated documents |
---|---|---|
Mar 2023 | Submit the Terminology for Constrained-Node Networks document to the IESG for publication as Informational RFC |
draft-bormann-lwig-7228bis
|
Dec 2022 | Submit the CoAP security comparison document to the IESG for publication as an Information RFC |
draft-ietf-lwig-security-protocol-comparison
|
Done milestones
Date | Milestone | Associated documents |
---|---|---|
Done | Submit the minimal ESP guidance document to the IESG for publication as an Informational RFC |
rfc9333 (was draft-ietf-lwig-minimal-esp)
|
Done | Submit the TCP over constrained networks guidance document to the IESG for publication as an Informational RFC |
rfc9006 (was draft-ietf-lwig-tcp-constrained-node-networks)
|
Done | Submit the lightweight crypto implementation document to the IESG for publication as an Informational RFC | |
Done | Submit the energy efficient implementation guidance document to the IESG for publication as an Informational RFC | |
Done | Submit the minimal IKEv2 implementation document to the IESG for publication as an Informational RFC | |
Done | Submit the implementation guidance document to the IESG for publication as an Informational RFC | |
Done | Submit the terminology document to the IESG for publication as an Informational RFC |