IoT Architecture & Protocols

Chapter 5
Internet and Routing Protocols for IoT

Diploma in IOT
IoT Architecture & Protocols   •   Diploma

Internet and Routing Protocols for IoT

Introduction and Context

An Internet of Things (IoT) system is useful only when devices can exchange information reliably with applications, users, and other devices. This exchange requires more than a radio link. Devices need addresses, transport services, name resolution, configuration mechanisms, routing algorithms, security controls, and gateways that connect networks using different technologies.

IoT networks are heterogeneous. A temperature sensor may use IEEE 802.15.4, a gateway may use Ethernet or Wi-Fi, and the cloud service may communicate through IPv6 over the public Internet. These networks also differ greatly in bandwidth, power availability, memory, packet size, and reliability. Internet and routing protocols provide the common language that allows these different components to interoperate.

This chapter explains IPv4 and IPv6 addressing, subnetting, TCP and UDP, DNS and DHCP, 6LoWPAN, RPL, and gateway functions. Emphasis is placed on practical design decisions for constrained and heterogeneous IoT networks.

Learning Objectives

After studying this chapter, a learner should be able to:

  1. Explain the role of Internet, transport, configuration, and routing protocols in IoT.
  2. Distinguish IPv4 and IPv6 addressing and perform basic subnetting calculations.
  3. Select TCP or UDP for an IoT application and justify the choice.
  4. Describe the functions of DNS and DHCP in IP networks.
  5. Explain how 6LoWPAN adapts IPv6 to low-power wireless networks.
  6. Describe RPL concepts, including the DODAG, rank, and objective function.
  7. Explain how gateways connect constrained networks to enterprise and cloud systems.
  8. Identify major implementation, security, reliability, and governance challenges.

1. Protocol Layers in an IoT Network

A protocol is a defined set of rules for communication. In a typical IoT architecture, protocols operate at several layers:

LayerMain responsibilityExamples in IoT
Link and physicalLocal transmission and framingIEEE 802.15.4, Wi-Fi, Ethernet, cellular
AdaptationMakes Internet protocols suitable for special links6LoWPAN
NetworkAddressing and packet forwardingIPv4, IPv6, RPL
TransportEnd-to-end delivery between processesTCP, UDP
ApplicationMeaning and exchange of sensor dataCoAP, MQTT, HTTP, DNS, DHCP

The layers are logically separate but cooperate. For example, a sensor may generate a CoAP message, place it in UDP, encapsulate the UDP datagram in IPv6, compress the IPv6 headers through 6LoWPAN, and transmit the resulting frame over IEEE 802.15.4.

A protocol stack is not automatically efficient merely because it is standards-based. In constrained IoT, every additional byte can increase energy consumption and airtime. Designers therefore consider packet overhead, duty cycle, retransmissions, memory, latency, interoperability, and security.

2. IPv4 and IPv6 Addressing

2.1 IPv4

IPv4 uses a 32-bit address, normally written as four decimal octets, such as 192.168.10.25. Each octet has 8 bits and can represent values from 0 to 255. An IPv4 address consists conceptually of a network portion and a host portion. The subnet mask identifies which bits belong to the network.

For example, 192.168.10.25/24 has 24 network bits and 8 host bits. The corresponding mask is 255.255.255.0. The network address is 192.168.10.0 and the directed broadcast address is 192.168.10.255. In the traditional subnet calculation, usable host addresses are 192.168.10.1 through 192.168.10.254.

The general number of addresses in an IPv4 subnet with prefix length p is:

N = 2^(32 − p)

Here, N is the total number of addresses and p is the prefix length. In the traditional case, two addresses are reserved for the network and broadcast addresses, so the number of usable host addresses is:

H = 2^(32 − p) − 2

This subtraction does not apply universally. Point-to-point links, /31 networks, and special-purpose prefixes follow different operational rules. Therefore, the network design must specify the addressing convention being used.

Private IPv4 ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. These addresses are not globally routable and commonly require Network Address Translation (NAT) for Internet access. NAT can conserve addresses, but it complicates direct device reachability and end-to-end communication.

2.2 IPv6

IPv6 uses 128-bit addresses written as eight hexadecimal groups, for example:

2001:db8:1234:0001:0000:0000:0000:0025

Leading zeroes in a group may be omitted, and one consecutive sequence of zero groups may be replaced by ::. The address above can therefore be written as 2001:db8:1234:1::25.

IPv6 provides an extremely large address space, hierarchical routing, automatic configuration mechanisms, multicast support, and improvements for end-to-end connectivity. Common address types are:

  • Global unicast: globally routable addresses.
  • Link-local: automatically formed addresses beginning with fe80::/10; used on the local link and for neighbour operations.
  • Unique local: addresses in fc00::/7, commonly used within private networks.
  • Multicast: addresses beginning with ff00::/8; IPv6 does not use broadcast in the IPv4 sense.
  • Loopback: ::1, used by a node to refer to itself.

IPv6 interface identifiers may be generated in several ways, including stable random procedures, privacy-oriented temporary identifiers, or link-layer-derived methods. A device should not expose unnecessary hardware-derived information in a public address.

IPv6 uses Neighbor Discovery Protocol (NDP), carried through ICMPv6, for functions such as router discovery, prefix discovery, address resolution, and duplicate address detection. Blocking ICMPv6 indiscriminately can break essential network operation.

2.3 Prefixes and Subnetting

An IPv6 prefix is written using slash notation, such as 2001:db8:abcd:1200::/64. The /64 indicates that the first 64 bits identify the subnet prefix. A /64 is a common subnet size for an IPv6 LAN, although other prefix lengths are used for routing and allocation.

#### Worked example: IPv4 subnetting

An organisation receives 192.168.40.0/24 and requires four equal-size subnets. Borrowing two host bits creates a /26 prefix because 24 + 2 = 26.

The number of addresses per subnet is:

N = 2^(32 − 26) = 64

Using the traditional host convention, usable hosts per subnet are:

H = 64 − 2 = 62

The four subnet ranges are:

SubnetNetwork addressUsable rangeBroadcast
1192.168.40.0/26.1–.62.63
2192.168.40.64/26.65–.126.127
3192.168.40.128/26.129–.190.191
4192.168.40.192/26.193–.254.255

The calculation assumes conventional IPv4 subnets and equal-size allocation. In production, variable-length subnetting may reduce address waste.

3. Transport Protocols: TCP and UDP

3.1 TCP

Transmission Control Protocol (TCP) provides a connection-oriented, reliable byte stream. Before application data is exchanged, TCP performs a three-way handshake: SYN, SYN-ACK, and ACK. TCP uses sequence numbers, acknowledgements, retransmission, flow control, and congestion control.

TCP is appropriate when data must arrive reliably and in order, such as firmware distribution, configuration transactions, and many web-based services. Its disadvantages for constrained devices include connection state, handshake overhead, larger implementation requirements, and energy costs associated with retransmissions and maintaining sessions.

TCP reliability does not mean that an application is automatically correct. A TCP connection can fail after a server has processed a request but before the client receives the response. Applications may therefore need request identifiers, timeouts, retries, and idempotent operations.

3.2 UDP

User Datagram Protocol (UDP) is connectionless and provides datagram delivery without built-in reliability, ordering, or congestion control. It has a smaller header and avoids a connection handshake. UDP is often suitable for short sensor messages, local discovery, time-sensitive telemetry, and protocols such as CoAP.

UDP reliability, if required, must be implemented by the application or an upper-layer protocol. Such mechanisms may include sequence numbers, acknowledgements, retransmission timers, duplicate detection, and rate limiting. UDP is not inherently insecure; security must be supplied through suitable mechanisms such as DTLS, OSCORE, or a protected network environment.

3.3 Selection criteria

The choice between TCP and UDP should be based on the application rather than habit.

RequirementUsually favours TCPUsually favours UDP
Reliable ordered byte streamYesNo
Very small request and responseSometimes inefficientYes
Intermittent sleeping devicesLess convenientOften more convenient
Built-in congestion controlYesMust be designed or supplied
Continuous connection stateRequiredNot required
Tolerance of occasional lossPoor fitGood fit if application permits

Applications must also account for maximum transmission unit (MTU). A packet that is too large for a constrained link may require fragmentation, increasing loss risk and memory requirements.

4. DNS and DHCP

4.1 Domain Name System

The Domain Name System (DNS) maps human-readable names to resource records. An A record maps a name to an IPv4 address, while an AAAA record maps a name to an IPv6 address. Other records include CNAME, MX, NS, and TXT.

DNS is hierarchical. A resolver may answer from its cache, contact an authoritative server, or use a recursive resolver. Caching reduces delay and traffic, but cached information remains valid only for the time specified by the record’s Time To Live (TTL).

IoT deployments may use DNS for cloud endpoints, local device services, service discovery, and certificate validation. A device should not blindly trust a name response. DNS security, transport protection, certificate validation, and resistance to spoofing must be considered.

4.2 DHCP

Dynamic Host Configuration Protocol (DHCP) supplies IPv4 configuration such as an address, subnet mask, default gateway, DNS server, and lease duration. The familiar IPv4 exchange is often described as DORA: Discover, Offer, Request, and Acknowledge.

IPv6 supports DHCPv6, but IPv6 hosts may also configure addresses through Stateless Address Autoconfiguration (SLAAC). Router Advertisements inform hosts about prefixes and default routers. DHCPv6 can provide additional configuration information and, depending on the design, address assignment.

In constrained networks, configuration traffic must be limited and carefully timed. Static addressing can simplify a small installation, but it becomes difficult to manage at scale. A practical deployment commonly combines stable device identity, automated address configuration, DNS registration, and an inventory system.

5. 6LoWPAN for Constrained Networks

6LoWPAN means IPv6 over Low-Power Wireless Personal Area Networks. It defines adaptation mechanisms that allow IPv6 packets to operate over IEEE 802.15.4 networks, which have small frames, low data rates, limited memory, and often multi-hop communication.

The principal 6LoWPAN functions are:

  1. Header compression: IPv6 and transport headers can be compressed when information is predictable from the link or context.
  2. Fragmentation and reassembly: An IPv6 packet larger than the link-layer frame can be divided into fragments.
  3. Mesh support: Packets may be forwarded across multiple low-power links, depending on the network design and adaptation approach.
  4. Address mapping: IPv6 link-local and interface addressing can be related to IEEE 802.15.4 addressing.

A conventional IPv6 minimum MTU is 1280 bytes, whereas an IEEE 802.15.4 frame has a much smaller maximum frame size and includes link-layer overhead. Consequently, an IPv6 packet may require fragmentation. Fragment loss can force reassembly failure, so applications should prefer compact messages and avoid unnecessary payload size.

6LoWPAN does not replace IPv6 routing. In a routed low-power mesh, RPL is commonly used above the adaptation layer. Nor does 6LoWPAN itself provide complete security. Link-layer encryption, end-to-end application security, key management, and device authentication remain necessary.

IoT sensor mesh connected through a 6LoWPAN border router Low-power IPv6 mesh S1 S2 S3 Borderrouter 6LoWPAN adaptation + RPL routing IPv6 networkCloud service IPv6 forwarding
IoT sensor mesh connected through a 6LoWPAN border router to an IPv6 cloud network
Figure: IoT sensor mesh connected through a 6LoWPAN border router to an IPv6 cloud network

Figure: A constrained 6LoWPAN mesh using RPL to reach an IPv6 cloud service through a border router.

6. RPL Routing for Low-Power and Lossy Networks

Routing Protocol for Low-Power and Lossy Networks (RPL) is designed for networks in which links may be unreliable, nodes may sleep, and energy and memory are limited. RPL constructs a Destination-Oriented Directed Acyclic Graph (DODAG). A DODAG is rooted at a coordinator, border router, or data-collection point.

Each node has a rank, representing its position relative to the root. Rank is not necessarily a simple hop count. An objective function determines how rank and parent selection are calculated. It may consider expected transmission count, latency, energy, link quality, or a combination of metrics.

RPL control messages include:

  • DIO: Disseminates information about the DODAG and allows nodes to discover it.
  • DIS: Requests DIO information from nearby nodes.
  • DAO: Advertises downward routes, depending on the mode of operation.
  • DAO-ACK: Acknowledges a DAO when acknowledgement is requested.

RPL supports upward traffic from sensors toward the root and can support downward traffic from the root toward sensors. Storing mode requires routers to maintain routing information for descendants. Non-storing mode places more route information at the root and may use source routing. The choice affects memory, packet overhead, and scalability.

A well-designed RPL network must avoid routing loops, unstable parent changes, overloaded root nodes, and excessive control traffic. The objective function should reflect the application. Choosing the lowest-latency path may consume more energy; choosing the lowest-energy path may increase delay. There is no universally best metric.

7. Gateways and Border Routers

A gateway connects networks that may use different addressing, link technologies, protocols, or security domains. In IoT, the term may refer to several functions:

  • Layer-3 border router: Routes IPv6 packets between a low-power mesh and another IPv6 network.
  • Protocol gateway: Translates between protocols, such as Modbus and MQTT.
  • Application gateway: Normalises data, applies rules, and exposes APIs.
  • Security gateway: Performs authentication, firewalling, certificate handling, or inspection.
  • Edge platform: Executes local analytics, buffering, device management, and control logic.

A pure router preserves end-to-end IP semantics. A translating gateway may terminate one protocol and create another session, which can improve interoperability but reduce transparency. For example, a gateway that converts proprietary sensor messages to MQTT may need to define data types, timestamps, units, quality flags, and error semantics.

Gateway design decisions include:

  1. Addressing: Will devices receive globally routable IPv6 addresses, private addresses, or gateway-managed identities?
  2. Data handling: Will raw data be forwarded, aggregated, filtered, or retained locally?
  3. Availability: What happens if the gateway loses cloud connectivity?
  4. Security: Where are keys stored, and where is trust enforced?
  5. Update management: Can gateway software and device firmware be updated securely?
  6. Time: How are timestamps synchronised when devices sleep or links are intermittent?

The gateway should not become an uncontrolled single point of failure. Redundant gateways, local buffering, health monitoring, and tested recovery procedures are important in industrial and safety-related systems.

8. Integrated Design Example

Illustrative case: Smart greenhouse monitoring

Background. A greenhouse operator wants to monitor temperature, humidity, soil moisture, and water-tank level. Battery-powered sensors are distributed across several growing zones. A mains-powered controller has Ethernet access to the farm network.

Problem. The sensors cannot use Wi-Fi continuously because of power limitations. The network must operate across multiple hops, continue collecting data during temporary Internet outages, and allow authorised operators to change irrigation thresholds.

Analysis. IEEE 802.15.4 is selected for the local low-power links. IPv6 connectivity is required for long-term interoperability. 6LoWPAN reduces header overhead and supports fragmentation where necessary. RPL provides multi-hop routing to the controller, which functions as a border router. UDP with a constrained application protocol is suitable for small telemetry messages, while a secured TCP-based connection may be used by the gateway to a cloud service when required.

The sensors use stable device identities and automatically obtain IPv6 configuration. DNS provides the cloud service name, while local configuration is distributed through IPv6 router advertisements and, where needed, DHCPv6. The gateway stores measurements locally when the backhaul is unavailable.

Approach and solution. The design uses:

  • IPv6 /64 prefixes for logical greenhouse segments.
  • 6LoWPAN over IEEE 802.15.4.
  • RPL with a link-quality and energy-aware objective function.
  • UDP for compact sensor readings with application acknowledgements for important commands.
  • End-to-end object security or DTLS according to the application protocol.
  • A gateway firewall that permits only required inbound and outbound flows.
  • Local validation so that irrigation can continue even when the cloud is unreachable.
  • Signed firmware updates and unique device credentials.

A measurement includes sensor identity, timestamp, value, unit, sequence number, and quality indicator. Sequence numbers help detect duplicates or missing readings. Commands are authenticated and authorised separately from ordinary telemetry.

Outcome. The design reduces radio activity, supports multi-hop coverage, and maintains local operation during backhaul failure. It also avoids assuming that the cloud is always available. The main operational requirements are battery monitoring, route-health observation, key rotation, firmware maintenance, and periodic testing of failover behaviour.

Learning points. Protocol selection must follow application requirements. A gateway should provide useful local autonomy rather than merely forwarding packets. Security, addressing, routing, and maintenance must be designed as one system.

9. Security, Governance, and Limitations

IoT routing and Internet connectivity create several security risks:

  • Address spoofing and unauthorised neighbour formation.
  • Rogue DHCP or router-advertisement messages.
  • DNS manipulation or fraudulent service endpoints.
  • Route poisoning, sinkhole behaviour, or denial of service in mesh routing.
  • Weak default credentials and poorly protected gateway interfaces.
  • Replay of valid sensor commands.
  • Exposure of device location or operational patterns through traffic analysis.

Security should be layered. Devices need unique identities, secure boot where feasible, signed firmware, least-privilege access, encrypted communication, key rotation, secure logging, and a plan for revocation. Link-layer encryption protects a local hop but does not necessarily protect data across gateways. End-to-end protection is therefore important for sensitive data.

Privacy and governance also matter. Sensor data may reveal occupancy, worker activity, health conditions, or production processes. Organisations should minimise collection, define retention periods, restrict access, document processing purposes, and comply with applicable data-protection and sector regulations.

Technical limitations include constrained memory, intermittent connectivity, radio interference, clock drift, limited battery energy, vendor incompatibility, and incomplete observability. A network that works in a laboratory may fail in a metal-rich industrial environment. Field surveys, capacity testing, packet-loss measurements, and staged deployment are essential.

10. Best Practices and Contemporary Developments

Good practice includes:

  1. Prefer IPv6 for new large-scale deployments, while planning carefully for IPv4 integration.
  2. Use clear address plans and document prefixes, gateways, and ownership.
  3. Keep application messages small and avoid unnecessary fragmentation.
  4. Select TCP or UDP according to reliability, latency, power, and session requirements.
  5. Use DNS names rather than hard-coded cloud addresses, but validate DNS responses and certificates.
  6. Monitor RPL parent changes, rank inconsistencies, packet loss, latency, and battery status.
  7. Separate device, management, guest, and critical-control traffic.
  8. Design for gateway failure and temporary cloud unavailability.
  9. Use secure provisioning instead of shared default keys.
  10. Test firmware updates, key replacement, recovery, and decommissioning before deployment.

Contemporary IoT systems increasingly use edge computing to reduce latency and bandwidth consumption. IPv6-only designs are becoming more practical, although dual-stack and translation mechanisms remain common. Low-power wide-area networks, time-sensitive industrial networks, and deterministic wireless systems introduce additional routing and service requirements. Artificial intelligence may assist with anomaly detection, route-quality prediction, or energy optimisation, but it should not replace protocol correctness, security controls, or engineering validation. AI-driven decisions must be explainable enough for operational diagnosis and must not silently alter safety-critical routing policies.

Chapter Summary

Internet and routing protocols form the foundation of interoperable IoT systems. IPv4 remains widely deployed, but IPv6 offers a large address space, autoconfiguration, multicast, and improved end-to-end scalability. Prefix lengths and subnet masks determine network capacity, and subnetting must be calculated according to the relevant addressing convention.

TCP provides reliable, ordered transport but introduces connection and state overhead. UDP is lightweight and appropriate for many constrained applications, although reliability and security must be supplied by suitable upper layers. DNS resolves service names, while DHCP, DHCPv6, SLAAC, and router advertisements support network configuration.

6LoWPAN adapts IPv6 to low-power IEEE 802.15.4 networks through compression, fragmentation, and related mechanisms. RPL builds DODAGs for low-power and lossy networks and selects routes using objective functions that may consider energy, quality, or latency. Gateways and border routers connect constrained meshes with enterprise and cloud networks, but their translation, security, and availability roles must be designed carefully.

A professional IoT deployment combines addressing, transport, routing, gateway operation, security, privacy, monitoring, and maintenance. Protocol choices should be driven by the physical environment and application requirements rather than by isolated technology preferences.

Key Terms

IPv4: A 32-bit Internet Protocol addressing system.

IPv6: A 128-bit Internet Protocol designed for a very large address space and modern network functions.

Prefix length: The number of leading address bits identifying a network or subnet.

Subnet mask: An IPv4 value identifying network and host portions of an address.

TCP: A connection-oriented transport protocol providing reliable ordered byte delivery.

UDP: A connectionless datagram transport protocol with low overhead.

DNS: A hierarchical system that maps names to network resource records.

DHCP: A protocol for dynamically supplying network configuration.

SLAAC: IPv6 Stateless Address Autoconfiguration.

6LoWPAN: Adaptation technology for carrying IPv6 over low-power wireless personal area networks.

RPL: Routing Protocol for Low-Power and Lossy Networks.

DODAG: Destination-Oriented Directed Acyclic Graph used by RPL.

Rank: A RPL measure of a node’s position relative to the DODAG root.

Objective function: Rules used to select RPL parents and calculate routing preferences.

Gateway: A device or software system connecting different networks or protocols.

Border router: A router connecting a constrained mesh to another IP network.

MTU: Maximum Transmission Unit, the largest packet payload supported by a link or interface.

NAT: Network Address Translation between address domains, commonly IPv4 private and public networks.

SLAAC: A method by which IPv6 nodes form addresses using advertised prefixes.

Review Questions

Short Answer Questions

  1. What is the principal difference between TCP and UDP?
  2. Why is IPv6 especially useful for large IoT deployments?
  3. State two functions performed by 6LoWPAN.
  4. What is the purpose of a RPL DODAG?
  5. What information can DNS provide to an IoT device?

Long Answer Questions

  1. Compare IPv4 and IPv6 addressing, including address size, configuration, broadcast or multicast behaviour, and IoT implications.
  2. Explain how 6LoWPAN and RPL cooperate in a low-power wireless mesh.
  3. Discuss the factors that should guide the selection of TCP or UDP for an IoT application.
  4. Describe the functions and security responsibilities of an IoT gateway.
  5. Explain how DHCP, DHCPv6, SLAAC, router advertisements, and DNS contribute to device configuration.

Analytical / Application Questions

  1. A company has the IPv4 network 192.168.50.0/24 and requires eight equal subnets. Determine the prefix length, total addresses per subnet, and traditional usable hosts per subnet. State your assumptions.
  2. Design a routing and gateway architecture for battery-powered environmental sensors spread across a warehouse with unreliable cloud connectivity. Justify the link, adaptation, routing, transport, and gateway choices.
  3. An RPL network experiences frequent parent changes and rapidly declining battery life. Analyse possible causes and propose measurements and corrective actions.

Multiple Choice Questions with Answers

Question 1

Which protocol provides a reliable, ordered byte stream between applications?

A. UDP

B. TCP

C. DNS

D. RPL

Correct Answer: B. TCP

Question 2

How many total IPv4 addresses are present in a conventional /26 subnet?

A. 32

B. 62

C. 64

D. 128

Correct Answer: C. 64

Question 3

Which IPv6 address type is normally used for communication only on the local link?

A. Global unicast

B. Link-local

C. Multicast-only global

D. Loopback of another host

Correct Answer: B. Link-local

Question 4

What is a primary purpose of 6LoWPAN?

A. Replacing all IPv6 routing protocols

B. Adapting IPv6 to low-power IEEE 802.15.4 networks

C. Providing public DNS registration

D. Encrypting every cloud database

Correct Answer: B. Adapting IPv6 to low-power IEEE 802.15.4 networks

Question 5

What structure does RPL construct for low-power and lossy networks?

A. DODAG

B. Ethernet collision domain

C. DNS zone

D. TCP byte stream

Correct Answer: A. DODAG

Question 6

Which DNS record maps a name to an IPv6 address?

A. A

B. AAAA

C. MX

D. TXT

Correct Answer: B. AAAA

Question 7

Which sequence correctly represents the common IPv4 DHCP exchange?

A. Discover, Offer, Request, Acknowledge

B. Request, Discover, Acknowledge, Offer

C. Offer, Discover, Acknowledge, Request

D. Acknowledge, Request, Offer, Discover

Correct Answer: A. Discover, Offer, Request, Acknowledge

Question 8

A gateway that routes IPv6 packets between a 6LoWPAN mesh and an Ethernet network is acting primarily as a:

A. Border router

B. DNS cache only

C. TCP checksum

D. Sensor actuator

Correct Answer: A. Border router

Question 9

Which transport protocol is generally more suitable when a message is short, occasional, and can tolerate application-managed reliability?

A. TCP

B. UDP

C. DHCP

D. IPv6

Correct Answer: B. UDP

Question 10

An IPv4 /24 network is divided into eight equal conventional subnets. What is the resulting prefix length?

A. /25

B. /26

C. /27

D. /28

Correct Answer: C. /27

IoT Architecture & Protocols
Chapter 5 of 14