8 Protocol Pioneers: IoT and 6LoWPAN

8.5.1 The Problem He Solved

In the 1990s, Kevin Ashton worked at Procter & Gamble in supply chain management. He noticed a frustrating pattern: stockouts — shelves ran out of popular products (like brown lipstick) while warehouses had plenty of inventory. Why?

The problem: Computers knew what inventory existed in databases, but they had no idea what was on store shelves. Humans had to manually count products and update systems. This was slow, error-prone, and expensive.

8.5.2 His Insight: Computers Need Their Own Senses

Ashton’s breakthrough insight in 1999:

“Computers need to sense the physical world directly, without depending on humans to input data. If things could identify themselves and report their location automatically, supply chains would fix themselves.”

He was experimenting with RFID (Radio Frequency Identification) tags — tiny chips that broadcast unique IDs when queried by a reader. Imagine if every lipstick had an RFID tag. Shelves could detect when stock was low and automatically reorder.

8.5.3 Coining “Internet of Things”

In 1999, Ashton gave a presentation to P&G executives about using RFID to track inventory. He needed a catchy phrase to capture the concept. He chose:

“Internet of Things”

The phrase stuck. It perfectly captured the vision: extend the Internet beyond computers to include everyday objects — thermostats, light bulbs, cars, containers, even lipstick.

8.5.4 How to Use: Why “Things” Instead of “Devices”?

Ashton chose “Things” deliberately:

• “Devices” sounds technical — implies electronics, computers, gadgets
• “Things” is universal — includes anything: a shipping container, a parking space, a tree, a pill bottle

The name signals that anything can be connected, not just traditional electronic devices.

8.5.5 How to Use: The Impact

“Internet of Things” became the standard term for connected devices. For scale, IoT Analytics projected 21.1 billion active IoT connections by the end of 2025 in its October 2025 update based on first-half data. IoT Analytics The IoT industry includes:

• Billions of connected devices worldwide, with counts depending on what is classified as IoT
• Hardware, platforms, and services across many markets; spending totals depend on which segments are counted
• Applications in every industry: healthcare, agriculture, manufacturing, transportation, energy, retail

Ashton didn’t invent the technology — RFID, sensors, and networking existed before 1999. But he articulated the vision and gave it a name that the industry rallied around.

8.6.1 The Problem He Solved

By the 2000s, Vint Cerf’s TCP/IP was the universal Internet protocol — but it was designed for computers with megabytes of RAM and wired networks with low error rates. IoT devices had:

• Kilobytes of RAM (not megabytes)
• Low-power radios (IEEE 802.15.4: 127-byte max packet size)
• Potential packet loss from interference, obstruction, or contention; the rate must be measured in the deployment

IPv6 headers alone are 40 bytes — plus 8 bytes for UDP. On a 127-byte 802.15.4 packet, headers consumed 38% of capacity before any application data! This was unsustainable.

8.6.2 His Breakthrough: 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks)

Geoff Mulligan led the IETF working group that created 6LoWPAN (RFC 4944, 2007), which makes IPv6 work on tiny devices:

Key Innovations:

1. Header Compression 6LoWPAN compresses IPv6’s 40-byte header down to as little as 2 bytes by:

• Omitting predictable fields (version, flow label)
• Using context to infer addresses (e.g., “the gateway” instead of full address)
• Encoding common patterns efficiently

2. Fragmentation and Reassembly IPv6 packets can be 1280+ bytes, but 802.15.4 only allows 127 bytes. 6LoWPAN fragments large packets at the adaptation layer and reassembles them at the destination.

3. Mesh Routing Support 6LoWPAN enables mesh networks where devices route packets for each other, extending network range without infrastructure.

8.6.3 How to Use: Why IPv6 for IoT?

Mulligan advocated for IPv6 (not IPv4) because:

• Address space: IPv6 provides $2^{128}$ addresses — enough for every grain of sand on Earth to have an IP address. IPv4’s $2^{32}$ addresses (4.3 billion) aren’t enough for tens of billions of IoT devices.
• End-to-end addressability: IPv6 can give devices globally routable addresses, although deployments may use private addresses, gateways, and firewalls.
• Simplified routing: IPv6’s larger address space allows hierarchical addressing, making routing more efficient.

8.6.4 How to Use: The Impact

6LoWPAN became the foundation for:

• Thread: The mesh networking protocol for smart homes (used by Google Nest, Apple HomePod, Matter devices) is built on 6LoWPAN
• Zigbee IP: Zigbee’s IP-based variant uses 6LoWPAN
• Industrial IoT: Low-power sensor networks in factories use 6LoWPAN for IPv6 connectivity

8.12.1 From Internet-Draft to RFC

A protocol travels a defined path before it becomes a standard. An author publishes an Internet-Draft; a working group discusses and revises it; if it reaches rough consensus it is published as an RFC with a permanent number. Foundational protocols carry famous numbers: IP is RFC 791, TCP is RFC 793, SMTP is RFC 821, and FTP is RFC 959.

RFCs also standardize how requirements are written. RFC 2119 defines the capitalized keywords MUST, SHOULD, and MAY, so a spec can state precisely what an implementation is required to do versus what is recommended or optional. That precision removes ambiguity that would otherwise break interoperability.

CoAP, the constrained-device web protocol, followed this route as RFC 7252 after years as Internet-Drafts in an IETF working group. Because it is an open RFC using RFC 2119 language, a sensor vendor and a cloud vendor can implement CoAP independently and still expect their products to interoperate. A proprietary protocol would offer no such guarantee across vendors.

8.12.2 Why Running Code Matters

The “running code” half of the motto protects against paper standards that look fine but cannot be built or do not interoperate. The IETF has historically wanted to see multiple independent implementations interoperate before a specification advances. A spec is only real when two teams who never coordinated can build it from the text alone and have it work.

This matters intensely for IoT, where devices from dozens of makers must coexist for a decade. A subtle ambiguity in a spec, such as an unclear default or under-specified error case, becomes thousands of incompatible devices in the field. Interoperability events, often called plugfests, and reference implementations flush out those ambiguities before the standard is final.

For example, two vendors might implement a new IoT protocol from its draft and discover they disagree on how to handle a missing option field. One implementation drops the message; the other assumes a default. Caught at a plugfest, the spec can be clarified before publication. Missed, the same ambiguity ships as a fleet-wide interoperability bug. Public RFCs, precise requirement language, and demonstrated running code are the machinery that lets a multi-vendor IoT ecosystem actually interoperate.

8.13.1 How to Use: Key Takeaways

In this chapter, you learned:

• The Internet has no single inventor — it’s the result of collaborative work by hundreds of engineers over 60+ years, with each pioneer building on previous contributions
• Paul Baran’s packet switching (1964) introduced distributed routing and redundant paths, concepts now used in Zigbee and Thread mesh networks
• Vint Cerf and Bob Kahn’s TCP/IP (1974) created the universal Internet protocol with the open architecture principle (any network can connect) and end-to-end reliability (intelligence at endpoints, not network core)
• Tim Berners-Lee’s World Wide Web (1989-91) introduced HTTP, HTML, and URLs — freely given to the world, enabling web-based IoT dashboards and REST APIs
• Ray Tomlinson’s email (1971) established the user@host addressing pattern that influenced hierarchical naming in IoT systems
• Radia Perlman’s Spanning Tree Protocol (1985) prevents network loops and enables plug-and-play Ethernet — used in every building network and industrial IoT deployment
• Bob Metcalfe’s Ethernet (1973) and Metcalfe’s Law ($V \propto n^2$) explain why interoperable IoT ecosystems (like Matter) are more valuable than proprietary ones
• Jon Postel’s robustness principle (“be conservative in what you send, liberal in what you accept”) guides protocol design and explains why diverse IoT vendors can interoperate
• Andy Stanford-Clark’s MQTT (1999) became widely used for IoT messaging with a fixed header as short as 2 bytes, QoS levels, and a publish/subscribe pattern
• Kevin Ashton coined “Internet of Things” (1999) and articulated the vision that computers need their own senses (sensors) to understand the physical world
• Geoff Mulligan’s 6LoWPAN (2007) compressed IPv6 headers to work on tiny devices, enabling Thread and Matter smart home ecosystems

8.13.2 How to Use: The Human Element in Protocols

Behind every protocol is a person solving a real problem:

• Baran needed resilience against nuclear strikes
• Cerf wanted universal connectivity despite heterogeneous networks
• Berners-Lee wanted physicists to share research papers
• Tomlinson wanted to message colleagues on different computers
• Perlman wanted redundant network links without loops
• Metcalfe wanted to share Xerox PARC’s laser printer
• Stanford-Clark needed to monitor oil pipelines via expensive satellites
• Ashton wanted to prevent lipstick stockouts in stores
• Mulligan needed IPv6 to work on devices with kilobytes of RAM

Understanding the human stories helps you appreciate why protocols are designed the way they are.