Adding SLAAC support

[dscso]

Could you please take a look if I am going the right way before I implement the whole thing :D

These are my ideas:

• creating a new socket type (heavily DHCP inspired)
• leave the IPv6 generation to the user of the library

My questions:

• how to handle DNS? SLAAC does not have DNS advertisement support

ref #570

[chrysn]

Leaving the IP generation to the user is a bit odd, but then again, better to have this in first and then add a way for the user to pick an automatism for it.

DNS through SLAAC just works (and has been standardized since 2010, but people kept repeating the talking point): The same Router Advertisement that gives you the prefix information and the routes will also give you (in option 25) the IP address of a recursive DNS server.

[chrysn]

Does this really get simpler by using a new socket type? There is already the ICMP socket, and that can be bound to the relevant ICMP identifiers for Router Advertisement and Neighbor Advertisement, and send Router / Neighbor Solicitation.

[dscso]

DNS through SLAAC just works (and has been standardized since 2010, but people kept repeating the talking point): The same Router Advertisement that gives you the prefix information and the routes will also give you (in option 25) the IP address of a recursive DNS server.

True you are right.

Anyways DNS parsing has to be added to smoltcp

[dscso]

1. The ICMP socket is a great idea I didn't see that. Do you think SLAAC shouldn't be handled from a users perspective? My thought was to handle it similarly to DHCP (see below), so that the user adds a SLAAC-like Socket, that requests and awaits a Router Advertisement and returns the Prefix, DNS and a IPv6 address suggestion (see 2.). The user of the library is then responsible to assign the IPv6 address + DNS to the interface. What do you think about this idea?

smoltcp/examples/dhcp_client.rs

Lines 60 to 77 in 1ff5bc4

	Some(dhcpv4::Event::Configured(config)) => {
	debug!("DHCP config acquired!");
	debug!("IP address: {}", config.address);
	set_ipv4_addr(&mut iface, config.address);
	if let Some(router) = config.router {
	debug!("Default gateway: {}", router);
	iface.routes_mut().add_default_ipv4_route(router).unwrap();
	} else {
	debug!("Default gateway: None");
	iface.routes_mut().remove_default_ipv4_route();
	}
	for (i, s) in config.dns_servers.iter().enumerate() {
	debug!("DNS server {}: {}", i, s);
	}
	}

2. Regarding IPv6 address generation, I could do the following:
   2.1 Either use (see below) for random address generation
   2.2 Or just use the mac address in the last 6 bytes of the IPv6 address

smoltcp/src/iface/interface/mod.rs

Line 132 in 99ddd22

pub random_seed: u64,

[chrysn]

ad 1., I think that many developers will eventually expect a choice akin to what NetworkManager gives you ("use MAC address based", "generate both and primarily use {which of them}"). I don't know enough about the scope of smoltcp yet to know whether that's a choice that smoltcp should offer, or embassy_net (although I'd hope that the crate that offers the options would take a smoltcp network stack, plus maybe an impl RngCore and impl embedded_hal_async::timer something, so it could be used outside embassy_net as well).

If DHCPv4 is implemented this way, it probably makes sense here as well; DHCPv4 also needs to have at least access to a timer, so whatever is done there sounds like a good template.

ad 2.1: You may not need a random number generator, just a stable per-device secret. RFC7217 is state of the art there.

ad 2.2: MAC addresses may just have 6 bytes, but there is an 8-byte form called the EUI-64 where they are embedded, and there are precise rules on how those wind up in the interface identifier (low 8 bytes) of an IPv6 address in section 2.5.1 of RFC4291. These are what gives you the typical "fe80::xXxx:xxff:fexx:xxxx" IPv6 addresses you may have seen. (Note how if you look at the output of ip -6 a, in the position of the X, the address differs from the MAC address; this was done so that you can assign addresses like "fe80::1" manually without conflicting with MAC addresses).

---

But having SLAAC implemented with a "proposing IPv6 addresses for DAD is up to the user" interface sounds totally sufficient to me as a first iteration, as long as the SLAAC can ask that user provided function for another address (eg. providing a DAD_Counter).

Note that I'm not really an expert on any of this, and have barely contributed to smoltcp at all, so take all I'm writing here with a grains of salt, minimum.