gnrc/ipv6_auto_subnets: init RPL root when adding a prefix #17350

benpicco · 2021-12-07T14:08:35Z

Contribution description

Currently there is no way to initialize a RPL root from the shell in the same way as with automatic prefix configuration.
This changes the nib prefix add command to use the same mechanism as uhcpc and dhcpv6 when adding a new prefix.

I also added this to the ipv6_auto_subnets as this was missing there before.

To avoid conflicts with heterogeneous downstream networks (wired and wireless downstream) I added a check to only initialize RPL on a wireless interface.

Testing procedure

Issues/PRs references

JKRhb

I tested the PR using you instructions and adding the prefix works fine :) I noticed, though, that removing the prefix with nib prefix del 7 2001:db8::/32 does not update the RPL root/instance table while the ifconfig gets properly updated. Is this something that should also be considered in this PR?

miri64 · 2022-01-04T19:10:35Z

I noticed, though, that removing the prefix with nib prefix del 7 2001:db8::/32 does not update the RPL root/instance table while the ifconfig gets properly updated. Is this something that should also be considered in this PR?

Does removing the prefix remove the address, too? If so, it should be updated as it would be when removing the address (best via the removal of the address), if not, the prefix list should be considered independent of the address list and the behavior is correct. Only question then is how RPL's PIO handles that situation.

JKRhb · 2022-01-04T19:28:16Z

Does removing the prefix remove the address, too?

The current behavior can be seen below: The address gets removed from the netif, but the instance table does not change. Is this correct or should the latter be updated as well?

> nib prefix add 7 2001:db8::/32
nib prefix add 7 2001:db8::/32
> rpl
rpl
instance table: [X]
parent table:   [ ]     [ ]     [ ]

instance [0 | Iface: 7 | mop: 2 | ocp: 0 | mhri: 256 | mri 0]
        dodag [2001:db8::e8ac:916:53b0:3ada | R: 256 | OP: Router | PIO: on | TR(I=[8,20], k=10, c=0)]
> ifconfig
ifconfig
Iface  7  HWaddr: 3A:DA  Channel: 26  NID: 0x23 
          Long HWaddr: EA:AC:09:16:53:B0:3A:DA 
          L2-PDU:102  MTU:1280  HL:64  RTR  
          6LO  IPHC  
          Source address length: 8
          Link type: wireless
          inet6 addr: fe80::e8ac:916:53b0:3ada  scope: link  VAL
          inet6 addr: 2001:db8::e8ac:916:53b0:3ada  scope: global  VAL
          inet6 group: ff02::2
          inet6 group: ff02::1
          inet6 group: ff02::1:ffb0:3ada
          inet6 group: ff02::1a
          
          Statistics for Layer 2
            RX packets 0  bytes 0
            TX packets 14 (Multicast: 14)  bytes 461
            TX succeeded 14 errors 0
          Statistics for IPv6
            RX packets 0  bytes 0
            TX packets 14 (Multicast: 14)  bytes 1208
            TX succeeded 14 errors 0

> nib prefix del 7 2001:db8::/32
nib prefix del 7 2001:db8::/32
> rpl
rpl
instance table: [X]
parent table:   [ ]     [ ]     [ ]

instance [0 | Iface: 7 | mop: 2 | ocp: 0 | mhri: 256 | mri 0]
        dodag [2001:db8::e8ac:916:53b0:3ada | R: 256 | OP: Router | PIO: on | TR(I=[8,20], k=10, c=0)]
> ifconfig
ifconfig
Iface  7  HWaddr: 3A:DA  Channel: 26  NID: 0x23 
          Long HWaddr: EA:AC:09:16:53:B0:3A:DA 
          L2-PDU:102  MTU:1280  HL:64  RTR  
          6LO  IPHC  
          Source address length: 8
          Link type: wireless
          inet6 addr: fe80::e8ac:916:53b0:3ada  scope: link  VAL
          inet6 group: ff02::2
          inet6 group: ff02::1
          inet6 group: ff02::1:ffb0:3ada
          inet6 group: ff02::1a
          
          Statistics for Layer 2
            RX packets 0  bytes 0
            TX packets 17 (Multicast: 17)  bytes 547
            TX succeeded 18 errors 0
          Statistics for IPv6
            RX packets 0  bytes 0
            TX packets 17 (Multicast: 17)  bytes 1436
            TX succeeded 17 errors 0

miri64 · 2022-01-05T00:57:50Z

But using ifconfig 7 del 2001:db8::e8ac:916:53b0:3ada is changing the instance ID? That was what I was asking previously, I guess...

miri64 · 2022-01-05T00:58:17Z

If not, than this is faulty behaviour, which is however unrelated to this PR as this would most likely also be the case in current master.

benpicco · 2022-01-06T16:10:34Z

So what should I do here - also update nib prefix del, or is this out of the scope of this PR?

miri64 · 2022-01-06T20:52:50Z

So what should I do here - also update nib prefix del, or is this out of the scope of this PR?

As already said before: I would prefer to rather hook this up with the address removal rather than the prefix removal (which in turn calls address removal anyway), as the RPL network is defined by its DODAG ID (of type IPv6 address, not IPv6 prefix). That said, since I imagine that this would also require some clean-up on the RPL handler's part, I think it is best to do this in a separate PR.

miri64 · 2022-01-06T20:54:08Z

As already said before: I would prefer to rather hook this up with the address removal rather than the prefix removal (which in turn calls address removal anyway), as the RPL network is defined by its DODAG ID (of type IPv6 address, not IPv6 prefix).

(this also makes the current behavior somewhat of a bug btw, since I don't think it is defined how a RPL network should operate with its DODAG ID address not assigned to an interface of the root)

JKRhb · 2022-01-07T11:07:42Z

I guess we could merge this PR then, right? (And deal with the prefix/address removal separately.)

sys/net/gnrc/routing/ipv6_auto_subnets/gnrc_ipv6_auto_subnets.c

sys/shell/commands/sc_gnrc_ipv6_nib.c

miri64 · 2022-01-07T13:45:00Z

Please try to use the addresses getter provided by NETAPI or the gnrc_netif_ipv6_addrs_get() helper. This way, this operation can be made more thread-safe.

benpicco · 2022-01-07T15:10:52Z

I don't follow - how is it any more thread safe to do

ipv6_addr_t addrs[CONFIG_GNRC_NETIF_IPV6_ADDRS_NUMOF];

idx = gnrc_netif_ipv6_add_prefix(netif, &pfx, pfx_len, valid_ltime, pref_ltime);
gnrc_netif_ipv6_addrs_get(netif, addrs, CONFIG_GNRC_NETIF_IPV6_ADDRS_NUMOF);
gnrc_rpl_configure_root(netif, &addrs[idx]);

How would an address that was just added be subject to change anyway? (And then we would actually want the current version of the address for the RPL root)

If the address changes gnrc_netif_get_by_ipv6_addr() in gnrc_rpl_root_instance_init() would fail to begin with, so copying the address here will not save us from such edge case.

benpicco · 2022-01-20T16:15:52Z

ping @miri64 😉
That use case was actually the reason why gnrc_netif_ipv6_add_prefix() returns the index to the address array.
I don't see how copying the whole address array to the stack buys us anything here, if the address changes the rpl root would then be wrong.

miri64 · 2022-01-20T18:43:19Z

ping @miri64 wink
That use case was actually the reason why gnrc_netif_ipv6_add_prefix() returns the index to the address array.
I don't see how copying the whole address array to the stack buys us anything here, if the address changes the rpl root would then be wrong.

Fine, but then put at least a gnrc_netif_acquire()/gnrc_netif_release() around from before when you add a prefix to after when the address is added to RPL.

sys/net/gnrc/routing/ipv6_auto_subnets/gnrc_ipv6_auto_subnets.c

benpicco · 2022-01-20T20:14:36Z

Ok, added - I had to slightly modify gnrc_netif_ipv6_add_prefix() to avoid creating a dead-lock with the new locking.

benpicco · 2022-01-31T11:38:21Z

ping @miri64 😉

miri64 · 2022-02-25T16:04:05Z

sys/net/gnrc/routing/rpl/gnrc_rpl.c

+ /* only run RPL on wireless interfaces */
+ if (gnrc_netapi_get(netif->pid, NETOPT_IS_WIRED, 0, NULL, 0) == 1) {
+ return;
+ }


Mh... I know defacto it doesn't make sense to run RPL over a wired network, but e.g. for virtualization this might still be important (e.g. many testings of RPL were done with DESVirt on native' TAP if I remember correctly). Does it maybe make more sense to make this dependent on other factors e.g. if a the given OFs can be calculated?

many testings of RPL were done with DESVirt on native TAP if I remember correctly

Doesn't it make much more sense to use ZEP for that?
Actually this whole PR only exists to enable testing of RPL on CI using ZEP - #17353

Does it maybe make more sense to make this dependent on other factors e.g. if a the given OFs can be calculated?

But OF0 can always be calculated.

If we want a TAP interface to simulate a wireless link, we should rather unset the NETOPT_IS_WIRED property there.

Actually this whole PR only exists to enable testing of RPL on CI using ZEP - #17353

I am not really clear, how this would help.

The idea is that adding a prefix via nib prefix add should behave the same as adding a prefix via router advertisement or adding a prefix via UHCP / DHCPv6.

Those will also init RPL on those interfaces, but when adding this I thought it would make sense no to do so for wired interfaces.

I can drop that commit if you prefer that.

The idea is that adding a prefix via nib prefix add should behave the same as adding a prefix via router advertisement or adding a prefix via UHCP / DHCPv6.

Those will also init RPL on those interfaces, but when adding this I thought it would make sense no to do so for wired interfaces.

Mh maybe then rather nib prefix add and rpl root should remain separate commands and not everything should be automated ;-).

There is now #17709

I have no experience with RPL, but quickly searching for wireless in RFC65550 shows to me that it is not strictly restricted to wireless interfaces.

1.2. Expectations of Link-Layer Type

In compliance with the layered architecture of IP, RPL does not rely
on any particular features of a specific link-layer technology. RPL
is designed to be able to operate over a variety of different link
layers, including ones that are constrained, potentially lossy, or
typically utilized in conjunction with highly constrained host or
router devices, such as but not limited to, low-power wireless or PLC
(Power Line Communication) technologies.

miri64 · 2022-02-25T18:59:46Z

The more I think of it and with the discussion unfolding in #17350 (review), I am getting more and more the feeling, that nib prefix add and rpl root (or their respective functions) should remain separate. Bootstrapping is nice, but it leads to unforeseen side-effects, I see more harm than good.

benpicco · 2022-02-25T19:08:31Z

I still would like to have fd660ec in - I think I just forgot that in the initial PR and it should behave the same as UHCP and DHCPv6.
But then I would also want 8ec0d7b because having a wired and a wireless downstream interface does not seem so unlikely.

I can drop 19c675e.
It would still be nice to have a more high-level command for adding a prefix as right now one has to

nib prefix add the prefix
ifconfig add an address based on the prefix
rpl init

This is easy to get wrong.

miri64 · 2022-02-25T19:17:55Z

It would still be nice to have a more high-level command for adding a prefix as right now one has to

I am not against that. I just think there might be harm in having too much bootstrapping in nib commands.

fabian18

The changes are very small and look similar as in DHCPv6 and UHCPC, so I think they make sense. But I have no experience with RPL, or ipv6_auto_subnets so far.

sys/net/gnrc/routing/ipv6_auto_subnets/gnrc_ipv6_auto_subnets.c

fabian18 · 2022-03-29T09:54:14Z

sys/net/gnrc/routing/rpl/gnrc_rpl.c

+ /* only run RPL on wireless interfaces */
+ if (gnrc_netapi_get(netif->pid, NETOPT_IS_WIRED, 0, NULL, 0) == 1) {
+ return;
+ }


I have no experience with RPL, but quickly searching for wireless in RFC65550 shows to me that it is not strictly restricted to wireless interfaces.

1.2. Expectations of Link-Layer Type

In compliance with the layered architecture of IP, RPL does not rely
on any particular features of a specific link-layer technology. RPL
is designed to be able to operate over a variety of different link
layers, including ones that are constrained, potentially lossy, or
typically utilized in conjunction with highly constrained host or
router devices, such as but not limited to, low-power wireless or PLC
(Power Line Communication) technologies.

benpicco · 2022-03-29T13:23:33Z

I guess if RPL works across multiple interfaces that would make sense?
But our implementation only uses a single interface, so replaying packets over that would not make sense as with all wired interfaces, all nodes connected to the wire should reach all messages, unlike with wireless interfaces.

benpicco · 2022-04-17T14:52:15Z

Would it make sense to only enable RPL for 6Lo interfaces instead?

miri64 · 2022-04-17T19:09:29Z

Would it make sense to only enable RPL for 6Lo interfaces instead?

No. RPL is not bound to 6LoWPAN, but can be used with any mesh network technology.

benpicco · 2022-04-29T20:56:23Z

Fine, then let's just drop 8ec0d7b

sys/net/gnrc/routing/ipv6_auto_subnets/gnrc_ipv6_auto_subnets.c

fabian18

Call sequence is as in dhcpv6 and uhcpc and initialization works.

> 2022-05-02 19:10:07,389 # ifconfig
2022-05-02 19:10:07,395 # Iface  6  HWaddr: 00:00  Channel: 26  Page: 0  NID: 0x23  PHY: O-QPSK 
2022-05-02 19:10:07,396 #           
2022-05-02 19:10:07,401 #           Long HWaddr: 4E:49:6F:54:4F:76:00:00 
2022-05-02 19:10:07,407 #            TX-Power: 0dBm  State: IDLE  max. Retrans.: 3  CSMA Retries: 4 
2022-05-02 19:10:07,414 #           AUTOACK  ACK_REQ  CSMA  L2-PDU:102  MTU:1280  HL:64  RTR  
2022-05-02 19:10:07,417 #           RTR_ADV  6LO  IPHC  
2022-05-02 19:10:07,420 #           Source address length: 8
2022-05-02 19:10:07,422 #           Link type: wireless
2022-05-02 19:10:07,428 #           inet6 addr: fe80::4c49:6f54:4f76:0  scope: link  VAL
2022-05-02 19:10:07,434 #           inet6 addr: fd00:a:a:8000:4c49:6f54:4f76:0  scope: global  VAL
2022-05-02 19:10:07,437 #           inet6 group: ff02::2
2022-05-02 19:10:07,439 #           inet6 group: ff02::1
2022-05-02 19:10:07,443 #           inet6 group: ff02::1:ff76:0
2022-05-02 19:10:07,446 #           inet6 group: ff02::1a
2022-05-02 19:10:07,447 #           
2022-05-02 19:10:07,451 # Iface  5  HWaddr: 4E:49:6F:54:00:00  Link: up 
2022-05-02 19:10:07,459 #           L2-PDU:1500  MTU:1500  HL:64  RTR  
2022-05-02 19:10:07,461 #           Source address length: 6
2022-05-02 19:10:07,463 #           Link type: wired
2022-05-02 19:10:07,466 #           inet6 addr: fe80::4c49:6fff:fe54:0  scope: link  VAL
2022-05-02 19:10:07,473 #           inet6 addr: fd00:a:a:0:4c49:6fff:fe54:0  scope: global  VAL
2022-05-02 19:10:07,475 #           inet6 group: ff02::2
2022-05-02 19:10:07,477 #           inet6 group: ff02::1
2022-05-02 19:10:07,481 #           inet6 group: ff02::1:ff54:0
2022-05-02 19:10:07,482 #           
> rpl
2022-05-02 19:10:11,976 # rpl
2022-05-02 19:10:11,977 # instance table:       [X]
2022-05-02 19:10:11,980 # parent table: [ ]     [ ]     [ ]
2022-05-02 19:10:11,980 # 
2022-05-02 19:10:11,986 # instance [0 | Iface: 6 | mop: 2 | ocp: 0 | mhri: 256 | mri 0]
2022-05-02 19:10:11,994 #       dodag [fd00:a:a:8000:4c49:6f54:4f76:0 | R: 256 | OP: Router | PIO: on | TR(I=[8,20], k=10, c=0)]

ACK.

benpicco · 2022-05-02T19:38:18Z

Thank you for the review!

benpicco requested a review from miri64 December 7, 2021 14:08

benpicco requested review from cgundogan, haukepetersen and PeterKietzmann as code owners December 7, 2021 14:08

github-actions bot added Area: network Area: Networking Area: sys Area: System labels Dec 7, 2021

benpicco added the Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation label Dec 7, 2021

benpicco mentioned this pull request Dec 7, 2021

tests/gnrc_rpl: add automated test for gnrc_rpl #17353

Merged

benpicco added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Dec 9, 2021

benpicco requested a review from JKRhb January 4, 2022 12:36

JKRhb reviewed Jan 4, 2022

View reviewed changes

miri64 reviewed Jan 7, 2022

View reviewed changes

sys/net/gnrc/routing/ipv6_auto_subnets/gnrc_ipv6_auto_subnets.c Outdated Show resolved Hide resolved

miri64 reviewed Jan 7, 2022

View reviewed changes

sys/shell/commands/sc_gnrc_ipv6_nib.c Outdated Show resolved Hide resolved

miri64 reviewed Jan 20, 2022

View reviewed changes

sys/net/gnrc/routing/ipv6_auto_subnets/gnrc_ipv6_auto_subnets.c Show resolved Hide resolved

benpicco removed the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jan 20, 2022

benpicco mentioned this pull request Jan 20, 2022

gnrc/ipv6_auto_subnets: allow to join multiple subnets #17547

Merged

benpicco requested a review from MichelRottleuthner as a code owner February 25, 2022 14:35

github-actions bot added the Area: tests Area: tests and testing framework label Feb 25, 2022

miri64 reviewed Feb 25, 2022

View reviewed changes

benpicco mentioned this pull request Feb 25, 2022

netdev_tap: make 'wired' property configurable #17709

Merged

benpicco force-pushed the gnrc_rpl/auto_init_on_prefix branch from 5e0cc46 to 3938375 Compare February 25, 2022 19:23

github-actions bot removed the Area: tests Area: tests and testing framework label Feb 25, 2022

benpicco changed the title ~~gnrc/ipv6_auto_subnets, gnrc_ipv6_nib_nc: init RPL root when adding a prefix~~ gnrc/ipv6_auto_subnets: init RPL root when adding a prefix Feb 25, 2022

benpicco force-pushed the gnrc_rpl/auto_init_on_prefix branch from 3938375 to 14d5681 Compare February 25, 2022 19:37

benpicco requested a review from fabian18 March 23, 2022 12:28

fabian18 reviewed Mar 29, 2022

View reviewed changes

benpicco force-pushed the gnrc_rpl/auto_init_on_prefix branch from 4771bd3 to 2add3dd Compare April 6, 2022 13:39

benpicco and others added 3 commits April 29, 2022 22:56

gnrc_netif: improve documentation of gnrc_netif_ipv6_add_prefix()

878596d

gnrc/ipv6_auto_subnets: auto init RPL root

3993fd7

gnrc/ipv6_auto_subnets: bail out early if adding prefix fails

5785856

benpicco force-pushed the gnrc_rpl/auto_init_on_prefix branch from 2add3dd to 5785856 Compare April 29, 2022 20:56

fabian18 reviewed May 1, 2022

View reviewed changes

sys/net/gnrc/routing/ipv6_auto_subnets/gnrc_ipv6_auto_subnets.c Outdated Show resolved Hide resolved

gnrc/ipv6_auto_subnets: bail out early if prefix stays the same

a881af8

fabian18 approved these changes May 2, 2022

View reviewed changes

benpicco merged commit 1b92fb9 into RIOT-OS:master May 2, 2022

benpicco deleted the gnrc_rpl/auto_init_on_prefix branch May 2, 2022 19:38

benpicco mentioned this pull request Jun 9, 2022

gnrc/ipv6_auto_subnets: always send RIO to upstream network #18187

Merged

chrysn added this to the Release 2022.07 milestone Aug 25, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gnrc/ipv6_auto_subnets: init RPL root when adding a prefix #17350

gnrc/ipv6_auto_subnets: init RPL root when adding a prefix #17350

benpicco commented Dec 7, 2021 •

edited

Loading

JKRhb left a comment

miri64 commented Jan 4, 2022

JKRhb commented Jan 4, 2022 •

edited

Loading

miri64 commented Jan 5, 2022

miri64 commented Jan 5, 2022 •

edited

Loading

benpicco commented Jan 6, 2022

miri64 commented Jan 6, 2022

miri64 commented Jan 6, 2022 •

edited

Loading

JKRhb commented Jan 7, 2022

miri64 commented Jan 7, 2022

benpicco commented Jan 7, 2022 •

edited

Loading

benpicco commented Jan 20, 2022

miri64 commented Jan 20, 2022

benpicco commented Jan 20, 2022 •

edited

Loading

benpicco commented Jan 31, 2022

miri64 Feb 25, 2022

benpicco Feb 25, 2022 •

edited

Loading

miri64 Feb 25, 2022

benpicco Feb 25, 2022

miri64 Feb 25, 2022

benpicco Mar 29, 2022

fabian18 Mar 29, 2022

miri64 commented Feb 25, 2022

benpicco commented Feb 25, 2022 •

edited

Loading

miri64 commented Feb 25, 2022

fabian18 left a comment

fabian18 Mar 29, 2022

benpicco commented Mar 29, 2022

benpicco commented Apr 17, 2022

miri64 commented Apr 17, 2022

benpicco commented Apr 29, 2022

fabian18 left a comment

benpicco commented May 2, 2022

gnrc/ipv6_auto_subnets: init RPL root when adding a prefix #17350

gnrc/ipv6_auto_subnets: init RPL root when adding a prefix #17350

Conversation

benpicco commented Dec 7, 2021 • edited Loading

Contribution description

Testing procedure

Issues/PRs references

JKRhb left a comment

Choose a reason for hiding this comment

miri64 commented Jan 4, 2022

JKRhb commented Jan 4, 2022 • edited Loading

miri64 commented Jan 5, 2022

miri64 commented Jan 5, 2022 • edited Loading

benpicco commented Jan 6, 2022

miri64 commented Jan 6, 2022

miri64 commented Jan 6, 2022 • edited Loading

JKRhb commented Jan 7, 2022

miri64 commented Jan 7, 2022

benpicco commented Jan 7, 2022 • edited Loading

benpicco commented Jan 20, 2022

miri64 commented Jan 20, 2022

benpicco commented Jan 20, 2022 • edited Loading

benpicco commented Jan 31, 2022

miri64 Feb 25, 2022

Choose a reason for hiding this comment

benpicco Feb 25, 2022 • edited Loading

Choose a reason for hiding this comment

miri64 Feb 25, 2022

Choose a reason for hiding this comment

benpicco Feb 25, 2022

Choose a reason for hiding this comment

miri64 Feb 25, 2022

Choose a reason for hiding this comment

benpicco Mar 29, 2022

Choose a reason for hiding this comment

fabian18 Mar 29, 2022

Choose a reason for hiding this comment

miri64 commented Feb 25, 2022

benpicco commented Feb 25, 2022 • edited Loading

miri64 commented Feb 25, 2022

fabian18 left a comment

Choose a reason for hiding this comment

fabian18 Mar 29, 2022

Choose a reason for hiding this comment

benpicco commented Mar 29, 2022

benpicco commented Apr 17, 2022

miri64 commented Apr 17, 2022

benpicco commented Apr 29, 2022

fabian18 left a comment

Choose a reason for hiding this comment

benpicco commented May 2, 2022

benpicco commented Dec 7, 2021 •

edited

Loading

JKRhb commented Jan 4, 2022 •

edited

Loading

miri64 commented Jan 5, 2022 •

edited

Loading

miri64 commented Jan 6, 2022 •

edited

Loading

benpicco commented Jan 7, 2022 •

edited

Loading

benpicco commented Jan 20, 2022 •

edited

Loading

benpicco Feb 25, 2022 •

edited

Loading

benpicco commented Feb 25, 2022 •

edited

Loading