SLAAC support

[Rahix]

I'd be interested in implementing IPv6 SLAAC support for smoltcp. I wonder what the best way to do this would be? I see DHCPv4 is implemented as a socket type. Would it be a good idea to go the same route here?

I did some first tests, starting an implementation outside of smoltcp, but got stuck as the IcmpSocket does not allow receiving the router advertisements (because its filters are too strict).

[astro]

What I really want for SLAAC is to participate in IPv6 Multicast Listener Discovery to that IPv6-aware Ethernet switches don't filter out the advertisements on the port that smoltcp is connected to.

That's why I started working on multicast in the first place. Sorry that I didn't make it beyond IPv4.

DHCPv4 was started as a RawSocket, and was later switched to its own socket type for the reasons discussed in #459.

[therealprof]

DHCPv4 is special as it kind of sits in between layers (which is also the reason why the responsibility for handling it is often divvied into a kernel and userspace part). SLAAC and DHCPv6 are much clearer cut and should be implementable with the just a few generic prerequisites:

• Support of multiple addresses per network interface
• Support for multicast addressing
• DAD (which in turn requires use of ND and ideally MLD as mentioned by @astro)

[dlrobertson]

@Rahix I never got around to implementing SLAAC when I implemented the basics of IPv6, but I was interested in it. I'd be happy to help where needed and could definitely assist in reviews.

[dscso]

Are there some updates related to this issue?
I am currently doing some very hacky thing to achieve IPv6 connectivity by compiling a static IPv6 address into my source code, and I'd like to do it the right way.
Are there already some implementation attempts yet? If so I'd be glad. Otherwise I'd might try my luck to implement SLAAC.

I was looking where to implement this, and I found this piece of code:

smoltcp/src/iface/interface/ipv6.rs

Lines 376 to 387 in ef67e7b

	Icmpv6Repr::EchoRequest {
	ident,
	seq_no,
	data,
	} => {
	let icmp_reply_repr = Icmpv6Repr::EchoReply {
	ident,
	seq_no,
	data,
	};
	self.icmpv6_reply(ip_repr, icmp_reply_repr)
	}

I think reacting on a Router Solicitation by adding an IP address could be a solution. The only problem is how to select the suffix.

I see 2 choices:

• use mac address
• user defined

the problem of the mac address is that it would not work if the router cdir is too small and the user defined option would be add a lot of complexity. Alternatively the user defined could be "seed based" so the user provides a seed to the network stack and the network stack generates the suffix based on the seed.

Alternatively it is also possible to do a more DHCPv4-like approach and build a SLAAC-"Socket" so the end-user has kinda full control over it.

Am I on the right path?

[chrysn]

@dsco, what state did you get this into?

I think reacting on a Router Solicitation by adding an IP address could be a solution. The only problem is how to select the suffix.

A host (ie. non-router) would send router solicitations but not react to them; it would react to a router advertisements.

Picking the interface identifier by MAC address is common (no worries about size: An IPv6 is always at least a /64, so the converted MAC address always fits). There are lots of techniques to avoid tracking from that, but I'd say let's get the easy things done first.

[dscso]

I think reacting on a Router Solicitation by adding an IP address could be a solution. The only problem is how to select the suffix.

I got this working by defining a new SLAAC socket type. I could create an PR so you could take a look.

Regarding techniques to avoid tracking, I'd leave that to the user of the lib, since it needs randomness which is highly platform specific.

I just copied the DHCPv4 implementation to SLAAC. You can just register a SLAAC socket and poll for a new Router Advertisement.

I didn't got working yet:

• stability
• requesting a Router Advertisement, rn you have to wait till another device joins the network so the router multicasts the Router Advertisement
• Testing

My main problem is how to do the DNS Server handling nicely, since SLAAC unlike DHCPv* does not support DNS Server advertising?

[bergzand]

I guess I'm the next person here who is interested in good IPv6 support with SLAAC support in smoltcp.

I'm willing to take over the work for SLAAC started by #948 (closed now).

From my side the main question is how this should be implemented. Given that SLAAC is fully contained in ICMPv6, I think it can be implemented in the ICMPv6 code. The other approach would be how @dscso implemented it, with a separate SLAAC socket.

What could be useful here is to extend the ip_addrs in the interface with the mechanism and lifetimes of the ip address. This makes it easy to separate out the different mechanisms through which an address is added to the interface and ignore the address when it expired or no longer preferred.

[chrysn]

As things are otherwise not linked yet: there is ongoing work in #1039 to fix this.