IPv6: implement source address candidate selection by OlegHahm · Pull Request #3561 · RIOT-OS/RIOT

OlegHahm · 2015-08-05T10:31:17Z

WIP, see http://tools.ietf.org/html/rfc6724#section-4

OlegHahm · 2015-08-05T10:31:40Z

Currently only the candidate address selection algorithm is implemented. The rest follows later today.

cgundogan · 2015-08-05T10:34:24Z

sys/net/network_layer/ng_ipv6/netif/ng_ipv6_netif.c

you might need to utilize the mutex of ng_ipv6_netif_t, before accessing any further members of this struct

Yep, see l514

nvm, you are using the mutex in L514

OlegHahm · 2015-08-05T22:31:26Z

~~Depends on #3573.~~

OlegHahm · 2015-08-06T15:13:52Z

~~Also depends on #3575 and #3577~~. Otherwise this is ready for review and testing.

miri64 · 2015-08-07T04:30:26Z

Just wondering: are anycast addresses excluded (or rather should they be) in this algorithm too?

OlegHahm · 2015-08-07T05:33:18Z

Not sure. First their are not explicitly mentioned - in fact I'm not even sure if comparison to anything else apart from link-local, site-local, and global unicast is described in the RFC, but since I have to compare the other types anyway to determine a global unicast address and it seems sensible to me, I did it this way. Second, is their a way to distinguish anycast addresses? A very brief look haven revealed anything, but maybe I gave up to quickly.

miri64 · 2015-08-07T06:04:48Z

Not sure. First their are not explicitly mentioned - in fact I'm not even sure if comparison to anything else apart from link-local, site-local, and global unicast is described in the RFC, but since I have to compare the other types anyway to determine a global unicast address and it seems sensible to me, I did it this way.

I'm not sure if anycast addresses are allowed to be source addresses… Too lazy to find a source right now, but they are definitely not global unicast addresses, as the name implies ;-).

Second, is their a way to distinguish anycast addresses? A very brief look haven revealed anything, but maybe I gave up to quickly.

Not syntactically, no. RFC 4291 states they should be marked as such on the interface. In our implementation this is achieved by the NG_IPV6_NETIF_ADDR_FLAGS_NON_UNICAST flag. You can use the ng_ipv6_netif_addr_is_non_unicast() function to check this for an address that is already assigned to the interface (be careful to use the right pointer) and the ng_ipv6_addr_is_multicast() function to exclude multicast addresses from the result set (when you test for global unicast addresses you already excluded those).

OlegHahm · 2015-08-07T07:27:54Z

I'm not sure if anycast addresses are allowed to be source addresses…

RFC6724 says:
" Removed restriction against anycast addresses in the candidate set of source addresses, since the restriction against using IPv6 anycast addresses as source addresses was removed in Section 2.6 of RFC 4291 [RFC4291]."

Too lazy to find a source right now, but they are definitely not global unicast addresses, as the name implies ;-).

I know.

OlegHahm · 2015-08-07T07:37:01Z

Rebased on master. Still depending on #3573.

OlegHahm · 2015-08-07T07:44:19Z

About the anycast addresses: Apparently they are not forbidden as source address, but also they are not explicitly mentioned as being preferred in any rule. From a logical point of view, it doesn't seem sensible to prefer an anycast address as source address if the destination address is anycast. What do you think?

miri64 · 2015-08-07T08:11:52Z

From a logical point of view, it doesn't seem sensible to prefer an anycast address as source address if the destination address is anycast.

why has the destination address anything to do with that (and by the way I don't understand your logical conclusion that src should be preferred as NOT being anycast when the dst IS anycast)

OlegHahm · 2015-08-07T08:27:57Z

why has the destination address anything to do with that

That's basically the only criteria for choosing the source address.

(and by the way I don't understand your logical conclusion that src should be preferred as NOT being anycast when the dst IS anycast)

That's not what I wrote. I say it doesn't seem to make sense to prefer the anycast address as source.

OlegHahm · 2015-08-07T09:15:14Z

Pushed some code size optimizations. Not longer dependent on #3573.

OlegHahm · 2015-08-07T12:26:37Z

Reading the RFC again I figured out that rule 2 isn't implemented properly.

OlegHahm · 2015-08-08T12:33:37Z

Hm, all the ways I tried so far are way too big. Hang on!

OlegHahm · 2015-08-12T23:31:48Z

addressed comments

OlegHahm · 2015-08-13T08:01:59Z

fixed a comment, that was a leftover from a previous version

miri64 · 2015-08-17T20:09:40Z

sys/net/network_layer/ng_ipv6/netif/ng_ipv6_netif.c

use @see tag + <a href="…">RFC 6724, section 4</a>

It's a C file, but sure, I can do.

OlegHahm · 2015-08-17T20:49:15Z

Hopefully addressed everything.

miri64 · 2015-08-17T21:01:43Z

Works! Let me have a last look at the code, then I'll ACK.

miri64 · 2015-08-17T21:04:37Z

ACK, please squash.

see http://tools.ietf.org/html/rfc6724#section-4 and http://tools.ietf.org/html/rfc6724#section-5

OlegHahm · 2015-08-17T21:11:48Z

squashed

Anycasts are not explicitly forbidden according to RFC6724, Appendix B.

OlegHahm · 2015-08-17T22:32:38Z

Fixed missing NG_IPV6_ADDR... ocurrences in unittests and squashed immediately.

IPv6: implement source address candidate selection

The comment exists since the introduction of the [original implementation], but its meaning is unclear and misleading, as the code doesn't do anything with link-local. [original implementation]: RIOT-OS#3561

OlegHahm added Area: network Area: Networking State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet NSTF labels Aug 5, 2015

OlegHahm assigned miri64 Aug 5, 2015

cgundogan reviewed Aug 5, 2015
View reviewed changes

OlegHahm force-pushed the ipv6_source_candidate_set branch from 433d611 to 5ff219e Compare August 5, 2015 22:30

OlegHahm added the State: waiting for other PR State: The PR requires another PR to be merged first label Aug 5, 2015

OlegHahm force-pushed the ipv6_source_candidate_set branch from 5ff219e to 9429c79 Compare August 6, 2015 15:13

OlegHahm removed the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Aug 6, 2015

OlegHahm added the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label Aug 6, 2015

OlegHahm force-pushed the ipv6_source_candidate_set branch from 9429c79 to 604e5dc Compare August 7, 2015 07:36

OlegHahm force-pushed the ipv6_source_candidate_set branch from 604e5dc to 92c69ee Compare August 7, 2015 09:14

OlegHahm removed the State: waiting for other PR State: The PR requires another PR to be merged first label Aug 7, 2015

OlegHahm mentioned this pull request Aug 7, 2015

bitfield: get first set bit #3573

Closed

OlegHahm added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Aug 7, 2015

OlegHahm force-pushed the ipv6_source_candidate_set branch from 92c69ee to 082ce7d Compare August 8, 2015 14:03

OlegHahm added the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label Aug 12, 2015

miri64 reviewed Aug 17, 2015
View reviewed changes

OlegHahm added 2 commits August 17, 2015 23:10

make: added dependency from ipv6_netif to bitfield

8b2d9bf

OlegHahm force-pushed the ipv6_source_candidate_set branch from 775e1c0 to 6ca74a7 Compare August 17, 2015 21:11

OlegHahm added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable labels Aug 17, 2015

unittests: fixed ipv6_netif tests

65e2acb

Anycasts are not explicitly forbidden according to RFC6724, Appendix B.

OlegHahm force-pushed the ipv6_source_candidate_set branch from 6ca74a7 to 65e2acb Compare August 17, 2015 22:32

OlegHahm added a commit that referenced this pull request Aug 17, 2015

Merge pull request #3561 from OlegHahm/ipv6_source_candidate_set

b68213a

IPv6: implement source address candidate selection

OlegHahm merged commit b68213a into RIOT-OS:master Aug 17, 2015

OlegHahm deleted the ipv6_source_candidate_set branch August 17, 2015 23:17

OlegHahm mentioned this pull request Aug 17, 2015

ng_ipv6_netif: ng_ipv6_netif_find_best_src_addr() doesn't take mc addresses scope into account #3061

Closed

miri64 mentioned this pull request Oct 9, 2019

gnrc/netif: don't treat link local differently in prefix matching #12404

Closed

Conversation

OlegHahm commented Aug 5, 2015

Uh oh!

OlegHahm commented Aug 5, 2015

Uh oh!

cgundogan Aug 5, 2015

Choose a reason for hiding this comment

Uh oh!

OlegHahm Aug 5, 2015

Choose a reason for hiding this comment

Uh oh!

cgundogan Aug 5, 2015

Choose a reason for hiding this comment

Uh oh!

OlegHahm commented Aug 5, 2015

Uh oh!

OlegHahm commented Aug 6, 2015

Uh oh!

miri64 commented Aug 7, 2015

Uh oh!

OlegHahm commented Aug 7, 2015

Uh oh!

miri64 commented Aug 7, 2015

Uh oh!

OlegHahm commented Aug 7, 2015

Uh oh!

OlegHahm commented Aug 7, 2015

Uh oh!

OlegHahm commented Aug 7, 2015

Uh oh!

miri64 commented Aug 7, 2015

Uh oh!

OlegHahm commented Aug 7, 2015

Uh oh!

OlegHahm commented Aug 7, 2015

Uh oh!

OlegHahm commented Aug 7, 2015

Uh oh!

OlegHahm commented Aug 8, 2015

Uh oh!

OlegHahm commented Aug 12, 2015

Uh oh!

OlegHahm commented Aug 13, 2015

Uh oh!

miri64 Aug 17, 2015

Choose a reason for hiding this comment

Uh oh!

OlegHahm Aug 17, 2015

Choose a reason for hiding this comment

Uh oh!

OlegHahm commented Aug 17, 2015

Uh oh!

miri64 commented Aug 17, 2015

Uh oh!

miri64 commented Aug 17, 2015

Uh oh!

OlegHahm commented Aug 17, 2015

Uh oh!

OlegHahm commented Aug 17, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants