Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitches6LoWPAN carries IPv6 over constrained IEEE 802.15.4 links by keeping two address layers distinct: IPv6 addresses identify network interfaces, while IEEE 802.15.4 addresses identify devices or hops on the wireless link. An adaptation layer maps between them, compresses IPv6 headers, and fragments datagrams that will not fit in a single radio frame. In a mesh-under network, an adaptation-layer mesh header can direct a frame across several wireless hops without intermediate nodes making IPv6 forwarding decisions.
What the two address types identify
An IPv6 address identifies an interface at the network layer. A node may have a link-local IPv6 address for communication on its local link and one or more addresses used for communication beyond that link. The IPv6 address is not the same thing as the IEEE 802.15.4 address, even when its interface identifier is derived from, or associated with, the device’s link-layer address.
An IEEE 802.15.4 frame carries link-layer source and destination addresses. These can be extended addresses or, where the network uses them, short addresses. They identify the sender and receiver relevant to that wireless transmission. In a multi-hop path, those frame addresses can change at each hop; the end-to-end IPv6 source and destination normally remain the same.
RFC 4944 defines how IPv6 is adapted to IEEE 802.15.4, including stateless address autoconfiguration, link-local address formation, unicast and multicast mapping, mesh addressing, fragmentation, and the adaptation-layer dispatch format. Autoconfiguration can associate an IPv6 interface identifier with link-layer information, but that does not make the two complete addresses interchangeable: the IPv6 address also has a network prefix, and compression may rely on shared context for that prefix.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
- CC2538 development board Zigbee/6LOWPAN learning
How IPv6 and IEEE 802.15.4 addresses are mapped
When an IPv6 packet is sent over a 6LoWPAN link, the adaptation layer encodes information needed to carry the IPv6 datagram through the wireless network. The IEEE 802.15.4 header handles delivery of a frame to its link-layer recipient; the IPv6 header identifies the packet’s network-layer endpoints. Address mapping connects these functions without collapsing them into one address.
- Link-local communication: The receiver is on the local 6LoWPAN link. LOWPAN_IPHC can often infer link-local address information from link-layer information, avoiding transmission of fields that can be reconstructed.
- Routable addresses: A routable IPv6 address includes a prefix that may not be inferable from the link-layer address alone. LOWPAN_IPHC can use shared context state to represent such address information compactly.
- Unicast and multicast: RFC 4944 specifies mappings for IPv6 unicast and multicast over IEEE 802.15.4. RFC 6282 adds IPHC compression options, including multicast-address compression; the encoded form depends on the address and what can be inferred or supplied from context.
For example, a device may use an IEEE 802.15.4 short address such as 0x1001 while its IPv6 interface has a link-local address such as fe80::1234. These illustrative values do not imply a particular derivation: the short address is a link-layer identifier, while the IPv6 address is a network-layer identifier. A real network’s address formation and compression depend on its addressing mode and configuration.
Mesh-under and route-over forwarding
The key distinction is where a multi-hop forwarding decision is made. In mesh-under, forwarding occurs below IP in the 6LoWPAN adaptation layer. In route-over, each 6LoWPAN router makes an IPv6 forwarding decision. The ns-3 6LoWPAN model documentation describes both approaches and cautions that RFC 4944 and RFC 6282 use different IPv6/MAC addressing schemes; an explanation or simulation should not silently mix those schemes.
| Aspect | Mesh-under | Route-over |
|---|---|---|
| Forwarding layer | Link/adaptation layer | IPv6 layer |
| Address used for a hop | IEEE 802.15.4 addresses identify the frame’s wireless sender and next-hop receiver; a mesh header can carry the final link-layer destination. | IPv6 addresses guide forwarding at each router; each wireless transmission still uses IEEE 802.15.4 link-layer addresses. |
| Routing state | Held by the mesh-under forwarding mechanism below IP. | Held by IPv6 routers for IP forwarding. |
| Interaction with IPv6 routing | Intermediate mesh forwarders can relay below IP without making an IPv6 routing decision. | Each 6LoWPAN router forwards the IPv6 packet toward its next IP hop. |
| Border-router example | The mesh can carry a frame to the border router’s link-layer address, with intermediate nodes forwarding at the adaptation layer. | The border router participates as an IPv6 router; other 6LoWPAN routers make IP-level forwarding decisions along the way. |
A mesh-under packet path
Consider a small illustrative network with three constrained nodes and a border router. The short addresses and IPv6 addresses below are examples only; their pairing does not assert an autoconfiguration rule.
Rank #2
- CC2530 for Zigbee Module UART Core Board Development Board CC2530F256 Serial Port Module 2.4GHz
| Device | IEEE 802.15.4 short address | Illustrative IPv6 address | Role |
|---|---|---|---|
| Node A | 0x1001 |
fe80::a |
Originating node |
| Node B | 0x1002 |
fe80::b |
Intermediate mesh forwarder |
| Node C | 0x1003 |
fe80::c |
Destination node |
| Border router | 0x1004 |
fe80::d |
Connects the 6LoWPAN link to an IPv6 network |
- Node A creates an IPv6 packet whose source is its IPv6 address and whose destination is Node C’s IPv6 address.
- For mesh-under delivery, A adds a mesh header identifying the final link-layer destination, Node C, and sends the first radio frame to its next-hop forwarder, Node B. The frame’s IEEE 802.15.4 destination is B, not C.
- Node B forwards the packet below IP toward C. It does not replace the IPv6 source or destination as an IP router would; it relays the mesh traffic using the mesh-under mechanism.
- Node C receives the packet and processes the IPv6 datagram addressed to its IPv6 interface.
If the destination is outside the local 6LoWPAN network, the border router becomes the point where the packet leaves that constrained link for the wider IPv6 network. In a route-over design, constrained routers along the way instead make IPv6 forwarding decisions, so the packet’s IP next hop and the link-layer recipient are relevant at each routed hop.
Why 6LoWPAN compresses IPv6 headers
IEEE 802.15.4 specifies a 127-byte MTU. RFC 6282 notes that this yields about 80 octets of actual MAC payload when security is enabled on links with throughput of 250 kbps or less. That payload must accommodate adaptation information as well as the compressed or uncompressed IPv6 datagram, so a full IPv6 header can consume a substantial share of the available space.
RFC 4944’s original compression approach included HC1 and HC2. RFC 6282 updates that approach with LOWPAN_IPHC for IPv6 header compression and LOWPAN_NHC for compression of UDP and extension headers. IPHC can omit or shorten fields when their values can be inferred from the link, represented by a shared context, or otherwise recovered from the encoding. It is not a fixed-size replacement header: the result depends on the packet’s addresses, fields, and available context.
| Approach | What it covers | Address and context behavior | Size and multi-hop implications |
|---|---|---|---|
| HC1/HC2 | The original RFC 4944 compression approach for IPv6, with HC2 for transport information such as UDP. | More limited than the later IPHC scheme; it should not be treated as interchangeable with RFC 6282’s address encoding. | This article does not state a general header-size figure for HC1/HC2. Do not apply IPHC’s best-case sizes to HC1. |
| LOWPAN_IPHC/NHC | RFC 6282’s IPv6 compression, with NHC for UDP and extension headers. | Can exploit link-local information and shared context for routable address prefixes; includes multicast compression options. | IPHC’s best-case link-local figure is two octets; a stated multi-hop IP-routing case is seven octets, under the conditions described below. |
What the two- and seven-octet figures mean
RFC 6282 gives a best case in which LOWPAN_IPHC reduces the IPv6 header to two octets: the dispatch octet and the LOWPAN_IPHC encoding, for link-local communication. This is a best-case compressed representation, not the size of every IPv6 header on a 6LoWPAN.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
- 【Outstanding Performance】We use high-quality materials to ensure a perfect fit between all components and equipment.
- 【Product Quality】Installation is simple, saving time and effort.
- 【Professional Factory】We have a professional factory, and all products comply with safety standards.
- 【Excellent Service】We have a professional team to provide support for you，If you have any questions, please contact us promptly.
- 【Reservation Confirmation】Please verify the product model and applicable year to ensure it meets your needs.
For a multi-hop IP-routing case, the compressed representation can be seven octets: a dispatch octet, IPHC encoding, hop limit, and two-byte source and destination address fields. That figure belongs to the described encoding case; other addresses, fields, contexts, or packet requirements can change the size.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When a 6LoWPAN packet needs fragmentation
Fragmentation is needed when the IPv6 datagram, after its adaptation headers and other per-frame overhead are accounted for, cannot fit in one IEEE 802.15.4 frame’s available payload. This can occur because the radio-frame budget is small, even though header compression has reduced the IPv6 overhead. Security and MAC addressing also consume capacity, so the 127-byte MTU is not 127 bytes of application data.
RFC 4944 defines adaptation-layer fragmentation for datagrams that must cross the constrained link in multiple frames. The receiver uses the fragmentation information to reassemble the datagram before IPv6 processes it. If a datagram fits in one frame, fragmentation is unnecessary; if it does not, each fragment has less room for payload because it also carries its own link-layer and adaptation-layer information.
How headers are ordered
When more than one RFC 4944 adaptation header is present, the defined order is mesh addressing, broadcast, fragmentation, then the IPv6 or compressed payload. This layering keeps mesh delivery and frame-level adaptation ahead of the network-layer datagram. RFC 6282 supplies the newer IPHC/NHC compression formats for the payload portion; it does not erase the distinction between the underlying RFC 4944 adaptation functions and the newer compression behavior.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
