1.. _ip_stack_overview: 2 3Overview 4######## 5 6.. contents:: 7 :local: 8 :depth: 2 9 10Supported Features 11****************** 12 13The networking IP stack is modular and highly configurable via build-time 14configuration options. You can minimize system memory consumption by enabling 15only those network features required by your application. Almost all features 16can be disabled if not needed. 17 18* **IPv6** The support for IPv6 is enabled by default. Various IPv6 sub-options 19 can be enabled or disabled depending on networking needs. 20 21 * Developer can set the number of unicast and multicast IPv6 addresses that 22 are active at the same time. 23 * The IPv6 address for the device can be set either statically or 24 dynamically using SLAAC (Stateless Address Auto Configuration) 25 (`RFC 4862 <https://tools.ietf.org/html/rfc4862>`_). 26 * The system also supports multiple IPv6 prefixes and the maximum 27 IPv6 prefix count can be configured at build time. 28 * The IPv6 neighbor cache can be disabled if not needed, and its size can be 29 configured at build time. 30 * The IPv6 neighbor discovery support 31 (`RFC 4861 <https://tools.ietf.org/html/rfc4861>`_) is enabled by default. 32 * Multicast Listener Discovery v2 support 33 (`RFC 3810 <https://tools.ietf.org/html/rfc3810>`_) is enabled by default. 34 * IPv6 header compression (6lo) is available for IPv6 connectivity for 35 IEEE 802.15.4 networks (`RFC 4944 <https://tools.ietf.org/html/rfc4944>`_). 36 37* **IPv4** The legacy IPv4 is supported by the networking stack. It 38 cannot be used by IEEE 802.15.4 as this network technology supports 39 only IPv6. IPv4 can be used in Ethernet based networks. By default 40 IPv4 support is disabled. 41 42 * DHCP (Dynamic Host Configuration Protocol) client is supported 43 (`RFC 2131 <https://tools.ietf.org/html/rfc2131>`_). 44 * The IPv4 address can also be configured manually. Static IPv4 addresses 45 are supported by default. 46 47* **Dual stack support.** The networking stack allows a developer to configure 48 the system to use both IPv6 and IPv4 at the same time. 49 50* **UDP** User Datagram Protocol 51 (`RFC 768 <https://tools.ietf.org/html/rfc768>`_) is supported. 52 The developer can send UDP datagrams (client side support) or create a 53 listener to receive UDP packets destined to certain port (server side 54 support). 55 56* **TCP** Transmission Control Protocol 57 (`RFC 793 <https://tools.ietf.org/html/rfc793>`_) is supported. Both server 58 and client roles can be used the application. The amount of TCP sockets 59 that are available to applications can be configured at build time. 60 61* **BSD Sockets API** Support for a subset of a 62 :ref:`BSD sockets compatible API <bsd_sockets_interface>` is 63 implemented. Both blocking and non-blocking datagram (UDP) and stream (TCP) 64 sockets are supported. 65 66* **Secure Sockets API** Experimental support for TLS/DTLS secure protocols and 67 configuration options for sockets API. Secure functions for the implementation 68 are provided by mbedTLS library. 69 70* **MQTT** Message Queue Telemetry Transport (ISO/IEC PRF 20922) is supported. 71 A sample :zephyr:code-sample:`mqtt-publisher` client application for MQTT v3.1.1 is 72 implemented. 73 74* **CoAP** Constrained Application Protocol 75 (`RFC 7252 <https://tools.ietf.org/html/rfc7252>`_) is supported. 76 Both :zephyr:code-sample:`coap-client` and :zephyr:code-sample:`coap-server` sample 77 applications are implemented. 78 79* **LWM2M** OMA Lightweight Machine-to-Machine Protocol 80 (`LwM2M specification 1.0.2`_) is supported via the "Bootstrap", "Client 81 Registration", "Device Management & Service Enablement" and "Information 82 Reporting" interfaces. The required core LwM2M objects are implemented as 83 well as several IPSO Smart Objects. (`LwM2M specification 1.1.1`_) is 84 supported in similar manner when enabled with a Kconfig option. 85 :zephyr:code-sample:`lwm2m-client` sample implements the library as an example. 86 87* **HTTP** Hypertext Transfer Protocol client and server are supported. 88 :ref:`http_client_interface` library supports HTTP/1.1 (`RFC 2616`_). 89 :ref:`http_server_interface` library supports HTTP/1.1 (`RFC 2616`_) and 90 HTTP/2 (`RFC 9113`_). 91 :zephyr:code-sample:`sockets-http-client` and 92 :zephyr:code-sample:`sockets-http-server` samples are provided. 93 94* **DNS** Domain Name Service 95 (`RFC 1035 <https://tools.ietf.org/html/rfc1035>`_) client functionality 96 is supported. 97 Applications can use the DNS API to query domain name information or IP 98 addresses from the DNS server. Both IPv4 (A) and IPv6 (AAAA) records can 99 be queried. 100 Both multicast DNS (mDNS) (`RFC 6762 <https://tools.ietf.org/html/rfc6762>`_) 101 and link-local multicast name resolution 102 (LLMNR) (`RFC 4795 <https://tools.ietf.org/html/rfc4795>`_) are supported. 103 104* **Network Management API.** Applications can use network management API to 105 listen management events generated by core stack when for example IP address 106 is added to the device, or network interface is coming up etc. 107 108* **Wi-Fi Management API.** Applications can use Wi-Fi management API to 109 manage the interface, in example to connect to Wi-Fi network and to scan 110 available Wi-Fi networks. 111 112* **Wi-Fi Network Manager API.** Wi-Fi Network Managers can now register 113 themselves to the Wi-Fi stack. The Network Managers can then implement 114 the Wi-Fi Management API and manage the Wi-Fi interface. 115 116* **Multiple Network Technologies.** The Zephyr OS can be configured to 117 support multiple network technologies at the same time simply by enabling 118 them in Kconfig: for example, Ethernet, Wi-Fi and 802.15.4 support. Note 119 that no automatic IP routing functionality is provided between these 120 technologies. Applications can send data according to their needs to desired 121 network interface. 122 123* **Minimal Copy Network Buffer Management.** It is possible to have minimal 124 copy network data path. This means that the system tries to avoid copying 125 application data when it is sent to the network. 126 127* **Virtual LAN support.** Virtual LANs (VLANs) allow partitioning of physical 128 ethernet networks into logical networks. 129 See :ref:`VLAN support <vlan_interface>` for more details. 130 131* **Network traffic classification.** The sent and received network packets can 132 be prioritized depending on application needs. 133 See :ref:`traffic classification <traffic-class-support>` for more details. 134 135* **Time Sensitive Networking.** The gPTP (generalized Precision Time Protocol) 136 is supported. See :ref:`gPTP support <gptp_interface>` for more details. 137 138* **Network shell.** The network shell provides helpers for figuring out 139 network status, enabling/disabling features, and issuing commands like ping 140 or DNS resolving. The net-shell is useful when developing network software. 141 See :ref:`network shell <net_shell>` for more details. 142 143Additionally these network technologies (link layers) are supported in 144Zephyr OS v1.7 and later: 145 146* IEEE 802.15.4 147* Bluetooth 148* Ethernet 149* SLIP (IP over serial line). Used for testing with QEMU. It provides 150 ethernet interface to host system (like Linux) and test applications 151 can be run in Linux host and send network data to Zephyr OS device. 152 153Source Tree Layout 154****************** 155 156The networking stack source code tree is organized as follows: 157 158``subsys/net/ip/`` 159 This is where the IP stack code is located. 160 161``subsys/net/l2/`` 162 This is where the IP stack layer 2 code is located. This includes generic 163 support for Ethernet, IEEE 802.15.4 and Wi-Fi. 164 165``subsys/net/lib/`` 166 Application-level protocols (DNS, MQTT, etc.) and additional stack 167 components (BSD Sockets, etc.). 168 169``include/net/`` 170 Public API header files. These are the header files applications need 171 to include to use IP networking functionality. 172 173``samples/net/`` 174 Sample networking code. This is a good reference to get started with 175 network application development. 176 177``tests/net/`` 178 Test applications. These applications are used to verify the 179 functionality of the IP stack, but are not the best 180 source for sample code (see ``samples/net`` instead). 181 182.. _LwM2M specification 1.0.2: 183 http://openmobilealliance.org/release/LightweightM2M/V1_0_2-20180209-A/OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf 184 185.. _LwM2M specification 1.1.1: 186 http://openmobilealliance.org/release/LightweightM2M/V1_1_1-20190617-A/ 187 188.. _RFC 2616: 189 https://tools.ietf.org/html/rfc2616 190 191.. _RFC 9113: 192 https://tools.ietf.org/html/rfc9113 193
