<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>IPv6, 6LoWPAN &amp; Mesh on Embedded Systems Development</title><link>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/</link><description>Recent content in IPv6, 6LoWPAN &amp; Mesh on Embedded Systems Development</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/index.xml" rel="self" type="application/rss+xml"/><item><title>IPv6 on Embedded Devices</title><link>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/ipv6-embedded/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/ipv6-embedded/</guid><description>&lt;h1 id="ipv6-on-embedded-devices"&gt;IPv6 on Embedded Devices&lt;a class="anchor" href="#ipv6-on-embedded-devices"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;IPv4 was never designed for billions of endpoints, and the workarounds — NAT, port forwarding, application-layer gateways — impose complexity that embedded devices should not carry. IPv6 eliminates NAT entirely. Every device gets a globally routable 128-bit address, end-to-end reachability becomes the default, and Stateless Address Autoconfiguration (SLAAC) removes the dependency on a DHCP server. For a sensor node behind three layers of NAT, the difference is fundamental: IPv6 means the device is addressable from anywhere without tunneling hacks.&lt;/p&gt;</description></item><item><title>6LoWPAN: IPv6 over 802.15.4</title><link>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/6lowpan/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/6lowpan/</guid><description>&lt;h1 id="6lowpan-ipv6-over-802154"&gt;6LoWPAN: IPv6 over 802.15.4&lt;a class="anchor" href="#6lowpan-ipv6-over-802154"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;The fundamental problem is arithmetic. An IPv6 header is 40 bytes. A UDP header is 8 bytes. That is 48 bytes of protocol overhead before a single byte of application data. An IEEE 802.15.4 frame has a maximum size of 127 bytes, and after the MAC header (9–23 bytes depending on addressing mode), frame check sequence (2 bytes), and optional security headers (5–14 bytes), the remaining payload is typically 72–102 bytes. Fitting a 48-byte IPv6+UDP header into an 80-byte payload leaves only 32 bytes for application data — barely enough for a sensor reading.&lt;/p&gt;</description></item><item><title>Thread &amp; OpenThread</title><link>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/thread-openthread/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/thread-openthread/</guid><description>&lt;h1 id="thread--openthread"&gt;Thread &amp;amp; OpenThread&lt;a class="anchor" href="#thread--openthread"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Thread is a mesh networking protocol built on 802.15.4 and 6LoWPAN, designed specifically for reliable, secure, low-power device-to-device communication in buildings. Where 6LoWPAN provides the compression and fragmentation layer, Thread adds mesh routing, self-healing topology management, device roles, and a complete security model. The result is an IP-based mesh network where every node has a routable IPv6 address and the network reconfigures itself when nodes join, leave, or fail.&lt;/p&gt;</description></item><item><title>Matter Protocol: Network Fundamentals</title><link>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/matter-network-layer/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/matter-network-layer/</guid><description>&lt;h1 id="matter-protocol-network-fundamentals"&gt;Matter Protocol: Network Fundamentals&lt;a class="anchor" href="#matter-protocol-network-fundamentals"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Matter is an application-layer protocol for smart home devices that runs over three transport networks: WiFi, Thread, and Ethernet. BLE is used exclusively for commissioning — the initial pairing process that provisions network credentials — and is not used for runtime communication. This multi-transport approach means a Matter light bulb on Thread and a Matter thermostat on WiFi can communicate through a shared controller without protocol translation, because both speak the same IPv6-based application protocol.&lt;/p&gt;</description></item><item><title>Mesh Networking Topologies &amp; Trade-offs</title><link>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/mesh-topologies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://applied-ee.github.io/embedded/docs/networking/ipv6-mesh/mesh-topologies/</guid><description>&lt;h1 id="mesh-networking-topologies--trade-offs"&gt;Mesh Networking Topologies &amp;amp; Trade-offs&lt;a class="anchor" href="#mesh-networking-topologies--trade-offs"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;Mesh networking enables devices to relay messages for each other, extending coverage beyond the range of any single radio. The appeal is obvious: no single point of failure, self-healing paths, and coverage that scales with device count rather than AP placement. The cost is equally real: higher power consumption for routing devices, increased latency per hop, protocol complexity, and failure modes that are harder to diagnose than a simple star topology.&lt;/p&gt;</description></item></channel></rss>