ipv6_netif: initialize device dependent values #2944
Conversation
miri64
added
Type: enhancement
miri64
force-pushed
the
ipv6_netif/opt/auto-init-addr
branch
from
6da46d5 to
2c053d5
Compare
|
Rebased to current #2901 and added some fixes |
miri64
force-pushed
the
ipv6_netif/opt/auto-init-addr
branch
2 times, most recently
from
c159fa5 to
a7dd794
Compare
|
Rebased to current master and #2901 |
miri64
force-pushed
the
ipv6_netif/opt/auto-init-addr
branch
from
a7dd794 to
8d02890
Compare
miri64
removed
the
State: waiting for other PR
|
Rebased to current master. It's also no more dependent on another PR |
| /* TODO: put this somewhere more central and L2 protocol dependent */ | ||
| #define IID_LEN (8) | ||
|
|
||
| static bool _hwaddr_to_iid(uint8_t *iid, const uint8_t *hwaddr, size_t hwaddr_len) |
There was a problem hiding this comment.
I actually would like to see this publicly available for other layers. The rationale is that I would use such a function in RPL, where I need to add an ipv6 address to the interface (prefix given during runtime). Maybe with some more abstractions so that I do not have to deal with hardware addresses in RPL (:
There was a problem hiding this comment.
The problem is that it is not really specified anywhere that this is the general way to do it... This function basically assumes that the address is either an EUI-64, a MAC-48, one of the short address representations of IEEE 802.15.4 (with PAN or without), or the 1-bit format we used with the cc1100 in the old stack. This is however by no means generally applicable.
There was a problem hiding this comment.
Just out of curiosity: what do you need the link-layer addresses in RPL for?
There was a problem hiding this comment.
RPL has an option to spread a prefix via control packets (very similar to the PIO of ND). Nodes receiving this prefix should use it to configure an ipv6 address on their interface.
I thought I can use the interface id to create a unique ipv6 address out of that prefix. Do you have any other suggestions how I can achieve this?
There was a problem hiding this comment.
Regardless of this issue (which is pretty complex, because it also includes how to auto-initialize addresses in general) we should really talk about this option, especially with regard to substitutable features in 6LoWPAN ND which I'm currently working on. Are you at the Institute or the Hack'n'ACK today?
There was a problem hiding this comment.
I am not at the institute right now, but I'll join the Hack'n'ACK later
| iid[7] = hwaddr[i++]; | ||
| break; | ||
|
|
||
| case 8: |
There was a problem hiding this comment.
That would mean more code.
There was a problem hiding this comment.
If I'm not mistaken
case 8:
...
break;
case 6:
...
break;
case 4:
...
case 2:
...
case 1:
...
break;
default:
...should result in the same code.
|
Shouldn't this also have dependency to |
|
I think now it does |
What are you talking about it already has this dependency: https://github.com/RIOT-OS/RIOT/blob/master/Makefile.dep#L162 |
miri64
force-pushed
the
ipv6_netif/opt/auto-init-addr
branch
from
8d02890 to
2459f50
Compare
|
Rebased to current master and addressed comments. |
miri64
force-pushed
the
ipv6_netif/opt/auto-init-addr
branch
from
c7fa53c to
74053c9
Compare
Yes, sorry, somehow assumed that this would introduce a new module. |
OlegHahm
added
the
CI: needs squashing
|
ACK |
miri64
force-pushed
the
ipv6_netif/opt/auto-init-addr
branch
from
74053c9 to
8633043
Compare
|
Squashed |
miri64
added
CI: ready for build
|
And go. |
ipv6_netif: initialize device dependent values
This auto-initializes device dependent values for IPv6 like the link-layer-address dependent IPv6 address or the 6LoWPAN flag. It also fixes some related output. ng_at86rf2xx needed an extra option for get.
Depends on #2901.