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 proposal. - 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 (e.g., AddressReRegistration()), reducing code complexity and improving maintainability.

• Week 2 (June 9 - June 15)

• Week 3 (June 16 - June 22)

• Week 4 (June 23 - 29)

• 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)