GSOC20256LoWPAN

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers

Back to GSoC 2025 projects

Project Overview

• Project Name: 6LoWPAN Neighbor Discovery Protocol
• Student: Boh Jie Qi
• Mentors: Tommaso Pecorella and Adnan Rashid
• Google page: link
• Proposal: link
• Project Goals: The 6LoWPAN-ND (RFCs 4944, 6775, and 8505) is a replacement for IPv6 DAD and NDP for 6LoWPAN networks, and it is important to ensure address uniqueness across a network that can potentially use different MAC/PHY layers. There is a model for 6LoWPAN-ND, but it is still not merged in the main ns-3 branch. The goal is to clean up the implementation, remove an actual limitation due to a questionable assumption, and to add the support for multi-hop operations (EDAR and EDAC messages).
• Repository: repo
• About Me: I am a pre-final undergraduate student at the National University of Singapore, and am super excited to be able to work with everyone at ns-3!

Milestones

Phase 1: Code Cleanup + Implementation with 6LBR and 6LN
Pull Request

• Code Refactoring
  • Helper methods to parse and validate packets: Extract helper methods for parsing and validating ND packets to improve modularity and readability.
    
  • General code cleanup: Restructure code in sixlowpan-nd-protocol.h/cc and remove unnecessary comments
    

• Bug Fixes
  • Disabling DAD: Disable DAD when necessary to comply with 6LoWPAN ND scenarios that bypass traditional IPv6 DAD
    
  • Address Registration Fixes: Analyse address registration flow, identify and fix bugs to ensure working address bootstrapping between singular 6LN and 6LBR
    

• Documentation
  • Create detailed flowcharts to visualize key functions and message handling paths in the 6LoWPAN ND protocol logic
  • Create report documenting design choices
  • Add Sphinx documentation detailing 6LoWPAN

• Features
  • Add working ROVR generation and validation

• Tests
  • Unit tests for packet parsing and packet validation
  • Tests for address registration of 1-10 6LNs with 1 6LBR

Phase 2: Implementation of EDAR/EDAC messages for multi-hop DAD

• Bug Fixes

• Documentation
  • Update Sphynx documentation to reflect newly supported topologies and features as part of the second phase

• Features
  • Add 6LR
  • Add working Transaction ID validation (RFC8505 5.2)
  • Add 6CIO Option in RS / RA packets

• Tests
  • Simulate multi-hop topology using Ipv6StaticRouting to emulate RPL behavior in its absence

Extra

• Add the all fields in the EARO used in Send-NS(EARO) and Receive-NA(EARO) message as defined in the following document
• Add support for RFC8505 EARO fields in packet dissection in Wireshark
• Document tweaks made to address registration delays

Weekly Updates

• Community Bonding Period Week 1 (May 12 - May 18)
  • Conducted an in-depth review of key specifications, including RFC 8505, RFC 6775, and RFC 4861, to build a strong foundation in IPv6 Neighbor Discovery and its 6LoWPAN optimizations.
  • Explored relevant ns-3 modules, focusing on src/sixlowpan, and reviewed RFC 4944 and RFC 6282 to understand 6LoWPAN fragmentation, compression, and adaptation mechanisms.
  • Forked the ns-3 development repository and set up a working environment with the legacy 6LoWPAN-ND implementation as a baseline for development.
  • Established communication channels with mentors via Zulip and Google Meet, and aligned on expectations, deliverables, and development workflow.

• Community Bonding Period Week 2 (May 19 - May 25)
  • Performed in-depth packet analysis of key 6LoWPAN-ND messages, including NS(EARO), NA(EARO), RS, and RA.
  • Developed and integrated helper methods for parsing and validating ND packets, enhancing modularity and code reuse.
  • Created initial unit tests in sixlowpan-nd-packet-test.cc to validate correctness of packet serialisation and deserialisation logic.

• Community Bonding Period Week 3 (May 25 - June 1)
  • Analyzed the sixlowpan-ping-test.cc example to understand and reproduce the issue of concurrent address registrations, as outlined in the original project description.
  • Conducted a detailed review of the NdiscCache implementation, focusing on the neighbor cache state transitions (e.g., STALE, REACHABLE, TENTATIVE, REGISTERED) during the address registration lifecycle.
  • Configured code linting tools and integrated debugging support within the development environment to streamline diagnostics and maintain code quality.

• Week 1 (June 2 - June 8)
  • Introduced a formalized, serial address registration state machine for 6LNs to ensure one address is registered at a time, eliminating issues caused by concurrent registrations. The full design rationale and implementation details were documented in the [ Phase 1 report] for reference and future extensibility.
  • Implemented clear control flow for AddressRegistration, AddressRegistrationTimeout, and AddressRegistrationSuccess to manage state transitions during the registration lifecycle in a structured and predictable manner.
  • Removed outdated and redundant scheduling logic (SixLowPanNdProtocol::AddressReRegistration), reducing code complexity and improving maintainability.
  • Created annotated flow diagrams using draw.io to visualize the address registration FSM and its interactions, aiding code readability.

• Week 2 (June 9 - June 15)
  • Implemented core logic for address registration in alignment with the serialized state machine design drafted previously
  • Resolved major functional bugs in the ND protocol stack, enabling successful end-to-end address registration for individual 6LNs.
  • Removed legacy variables and deprecated address re-registration code paths, streamlining protocol logic.
  • Wrote test: sixlowpan-reg-test.cc to simulate and validate bootstrapping and address registration for a simple setup 1 6LN with 1 6LBR.

• Week 3 (June 16 - June 22)
  • Reintroduced the m_addressRegistrationEvent scheduling mechanism within SixLowPanNdProtocol to restore proper handling of timed registration events.
  • Fixed key bug in SixLowPanNdProtocol::HandleSixLowPanNs: added early return logic and call to Icmpv6L4Protocol::HandleNS when EARO is absent and corrected retransmission counter increment behavior.
  • Rebased development branch onto the latest ns-3-dev master to maintain compatibility and integrate upstream changes.
  • Disabled default IPv6 Duplicate Address Detection (DAD) timeouts in favor of multicast Router Solicitation scheduling during 6LN initialization, aligning with 6LoWPAN-ND behaviour.

• Week 4 (June 23 - 29)
  • Implemented multicast Router Solicitation support for 6LNs via a new SixLowPanNdProtocol::SendSixLowPanMulticastRS method, with randomized jitter and retransmission timeout logic to reduce collision risk and improve robustness.
  • Introduced delayed periodic re-registration in SixLowPanNdProtocol::AddressRegistration and extended registration lifetimes (>1 month) to reduce control traffic overhead in LLNs.
  • Authored Sphinx documentation for 6LoWPAN-ND, adding it to sixlowpan.rst, covering protocol design, implementation details, and usage within the ns-3 framework.

• Week 5 (June 30 - July 6)

• Week 6 (July 7 - July 13)

• Week 7 (July 14 - July 20)

Readings

RFC4861 Neighbor Discovery for IP version 6 (IPv6)
RFC6775 Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
RFC8505 Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
RFC5175 IPv6 Router Advertisement Flags Option
Is 6LoWPAN-ND necessary? (Spoiler alert: Yes)