Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gnrc/ipv6_auto_subnets: add option to derive subnet prefix from EUI #21080

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

benpicco
Copy link
Contributor

@benpicco benpicco commented Dec 13, 2024

Contribution description

This adds the gnrc_ipv6_auto_subnets_eui pseudo-module.

We have a number of wireless 802.15.4 nodes that each have a set of wired nodes connected locally.

[6LBR] - - - - [6LR]----[Node A]
   ¦             |
   ¦             \------[Node B]
   ¦
    \ - - - - - [6LR]---[Node C]
                  |
                  \-----[Node D]

To limit communication over the wireless link (The gnrc_ipv6_auto_subnets sync algorithm creates O(n) messages and does not deal well with lost messages) an alternative scheme of assigning subnet prefixes is needed.

Since this is a local sensor network, we can just choose a sufficiently small upstream prefix (e.g. fd12::/16) and create the downstream network by filling in the remaining bits with the EUI of the downstream wired interface.

Testing procedure

We have an upstream router that distributes the fd12::/16 prefix on the wireless network:

make PREFIX_CONF=static IPV6_PREFIX="fd12::/16" -C examples/gnrc_border_router all term

A routing node that receives that prefix will create subnets for it's downstream interfaces based on their EUI

Iface  5  HWaddr: 12:84:0C:87:1F:B7 
          L2-PDU:1500  MTU:1500  HL:64  RTR  
          RTR_ADV  Source address length: 6
          Link type: wired
          inet6 addr: fe80::1084:cff:fe87:1fb7  scope: link  VAL
          inet6 addr: fd12:1284:c87:1fb7:1084:cff:fe87:1fb7  scope: global  VAL
          inet6 group: ff02::2
          inet6 group: ff02::1
          inet6 group: ff02::1:ff87:1fb7
          
Iface  6  HWaddr: 79:3B  Channel: 26  NID: 0x23  PHY: O-QPSK 
          Long HWaddr: A6:C9:C2:7B:CC:D1:79:3B 
           State: IDLE 
          ACK_REQ  L2-PDU:102  MTU:1280  HL:64  RTR  
          6LO  IPHC  
          Source address length: 8
          Link type: wireless
          inet6 addr: fe80::a4c9:c27b:ccd1:793b  scope: link  VAL
          inet6 addr: fd12::a4c9:c27b:ccd1:793b  scope: global  VAL
          inet6 group: ff02::2
          inet6 group: ff02::1
          inet6 group: ff02::1:ffd1:793b

A node on the downstream (wired) network is able to ping the 6LBR:

2024-12-13 14:13:08,806 # Iface  6  HWaddr: E2:F7:1F:FD:29:80 
2024-12-13 14:13:08,807 #           L2-PDU:1500  MTU:1500  HL:64  Source address length: 6
2024-12-13 14:13:08,807 #           Link type: wired
2024-12-13 14:13:08,808 #           inet6 addr: fe80::e0f7:1fff:fefd:2980  scope: link  VAL
2024-12-13 14:13:08,809 #           inet6 addr: fd12:1284:c87:1fb7:e0f7:1fff:fefd:2980  scope: global  VAL
2024-12-13 14:13:08,810 #           inet6 group: ff02::1
2024-12-13 14:13:08,810 #           inet6 group: ff02::1:fffd:2980
2024-12-13 14:13:08,811 #           inet6 group: ff02::1a          

2024-12-13 14:13:16,428 # ping 2001:db8:1::1
2024-12-13 14:13:16,434 # 12 bytes from 2001:db8:1::1: icmp_seq=0 ttl=63 time=5.035 ms
2024-12-13 14:13:17,429 # 12 bytes from 2001:db8:1::1: icmp_seq=1 ttl=63 time=4.978 ms
2024-12-13 14:13:18,432 # 12 bytes from 2001:db8:1::1: icmp_seq=2 ttl=63 time=3.025 ms
2024-12-13 14:13:18,433 # 
2024-12-13 14:13:18,434 # --- 2001:db8:1::1 PING statistics ---
2024-12-13 14:13:18,436 # 3 packets transmitted, 3 packets received, 0% packet loss
2024-12-13 14:13:18,437 # round-trip min/avg/max = 0.978/3.012/5.035 ms

Issues/PRs references

Copy link
Contributor

@mguetschow mguetschow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have enough knowledge on 6lo to judge the impact and fitness of this approach, but one minor comment below.

Copy link
Contributor

@fabian18 fabian18 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks fine. As auto_subnets is your creation I trust you testing.
You may squash and I will approve

@benpicco
Copy link
Contributor Author

Actually we can do a little better and preserve the unused bits e.g. when combining a /8 with a EUI-48 from an ethernet interface:

fd00::/8 dev #6 
fdd2:7c7c:6d94:4100::/56 dev #5 

@benpicco benpicco force-pushed the gnrc_ipv6_auto_subnets_eui branch from 3fa9881 to 1f3c056 Compare January 10, 2025 17:58
@benpicco benpicco added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jan 10, 2025
@benpicco benpicco force-pushed the gnrc_ipv6_auto_subnets_eui branch 2 times, most recently from dadfd4f to 74a311a Compare January 10, 2025 18:54
@benpicco benpicco force-pushed the gnrc_ipv6_auto_subnets_eui branch from 74a311a to a07f473 Compare January 10, 2025 18:55
@fabian18
Copy link
Contributor

Ok, I dont't wanna start bikeshedidng now, but since you did some changes with new_prefix_len, Is this something sensible to return from _init_sub_prefix{_eui}?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: build system Area: Build system Area: network Area: Networking Area: sys Area: System CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants