-
Notifications
You must be signed in to change notification settings - Fork 457
slaac: add initial stateless address autoconfiguration (SLAAC) implementation #1039
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
base: main
Are you sure you want to change the base?
Conversation
This commit splits the state maintenance from the poll function to a separate poll_maintenance function.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1039 +/- ##
==========================================
+ Coverage 80.84% 81.70% +0.85%
==========================================
Files 81 82 +1
Lines 28485 29501 +1016
==========================================
+ Hits 23029 24103 +1074
+ Misses 5456 5398 -58 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
My main comment is here is "Why limit SLAAC to any specific mediums?"
@@ -23,4 +28,9 @@ pub use self::interface::{ | |||
}; | |||
|
|||
pub use self::route::{Route, RouteTableFull, Routes}; | |||
#[cfg(all( | |||
feature = "proto-ipv6", | |||
any(feature = "medium-ethernet", feature = "medium-ieee802154") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SLAAC is a general IPv6 thing, why restrict it to any particular medium(s)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SLAAC generates an IP addr based on the MAC addr. With IP medium there's no MAC addr. How is it supposed to work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure for link-local address you want to use the MAC address (or equivalent) to generate it, but that's not quite the same for global or temporary addresses where you might want to hide your MAC address. I think in this case the user should be allowed to specify an interface identifier (which would be different from the MAC).
If Linux can do SLAAC for TUN devices, smoltcp can definitely do it for IP mediums.
EDIT: I'm looking at https://datatracker.ietf.org/doc/html/rfc4862#section-5.5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure for link-local address you want to use the MAC address (or equivalent) to generate it, but that's not quite the same for global or temporary addresses where you might want to hide your MAC address. I think in this case the user should be allowed to specify an interface identifier (which would be different from the MAC).
I prefer to leave the additional logic required to switch the generation of interface identifiers to a follow up PR as this PR is already complex enough.
If Linux can do SLAAC for TUN devices, smoltcp can definitely do it for IP mediums.
If there's a way to add an interface identifier to a Medium::Ip
Interface, it can be hooked in somehow. The whole process_ndisc
where this code hooks into is skipped on Medium::Ip
interfaces, so that would need to be modified. Not impossible, but also not sure if that must go in this PR.
Do you know if there's some special handling for SLAAC on Linux tun devices? Or does it always add a privacy address to that interface for slaac?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or does it always add a privacy address to that interface for slaac?
Yes
I prefer to leave the additional logic required to switch the generation of interface identifiers to a follow up PR as this PR is already complex enough.
Sure the additional logic isn't necessary for this PR, I'm just saying the any(feature = "medium-ethernet", feature = "medium-ieee802154")
isn't needed.
src/wire/ndiscoption.rs
Outdated
impl PrefixInformation { | ||
/// Validates the prefix information option against check a, b, c in | ||
/// https://www.rfc-editor.org/rfc/rfc4862#section-5.5.3 | ||
pub fn valid_prefix_info(&self) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This probably reads better?
pub fn valid_prefix_info(&self) -> bool { | |
pub fn is_valid_prefix_info(&self) -> bool { |
This PR adds
Cidr
and a LL addressInterface
This works by having a separate module to track the slaac state machine. The Interface module passes the received router advertisements to this module and polls this to query whether router solicitations must be send and whether the addresses and routes on the interface need to be synced with the slaac state.
Compared to the dhcpv4, this module modifies the address and route state on the
Interface
within the module itself without any outside glue or socket required.Currently there's no separate feature for slaac and it is pulled in when
proto-ipv6
together withmedium-ieee802154
ormedium-ethernet
is enabled. Done this way because I consider SLAAC to be an essential part of IPv6. However, I'm not opposed to adding a separate feature for slaac that depends onproto-ipv6
An example is provided that prints the addresses and routes on the interface every second for testing with router advertisement daemons such as radvd
Example output
Alternative to #948
I can split out the initial commits of this PR into separate PRs if needed to ease reviewing.