allow to specify source LLA's address

[skoef]

While this causes a breaking change in the way source_lla is configured, it could be an approach to allow for overriding the source link-layer address derived from the dialing interface.

This PR is in response to #26

[mdlayher]

Thanks for the PR. I would rather not break the existing configuration and would prefer to add new options if anything. It isn't clear to me if this behavior (advertising on behalf of another router) is actually allowed by the NDP RFCs. Do you have any references?

[skoef]

I agree that breaking changes are no desirable, this was merely a PoC and I'm happy to take any suggestions.

I'm not aware of any implementations out there sending RA's on behalf of another router, except my own, and I wouldn't be surprised if it is violating the RFC, but I'm not sure so I can lookup into this.

[mdlayher]

Cool! I will do some research as well.

Another approach would be to actually expose the corerad.Server type for consumption in other packages. I have been putting off some cleanup on that for quite a while. It's possible that that would be useful elsewhere too.

[skoef]

The RFC states:

router - a node that forwards IP packets not explicitly
addressed to itself.

which doesn't explicitly is the case when sending out RA's on behalf of another router, but later:

A router might want to send Router Advertisements without advertising
itself as a default router. For instance, a router might advertise
prefixes for stateless address autoconfiguration while not wishing to
forward packets. Such a router sets the Router Lifetime field in
outgoing advertisements to zero.

To me, that seems the RFC allows for hosts to send out RA's even if they don't forward packets but only for SLAAC (exactly my usecase).

[skoef]

I've cleaned up the PR a bit and this time it's not a breaking change. Let me know if you're happy with the lla_address config key, since the word address is in LLA already ofcourse. I could change it into ll_address with then the link with source_lla wouldn't be as evident.

[skoef]

@mdlayher any thoughts on this?

[mdlayher]

Wouldn't this problem be solved in the correct way by running multiple instances of a router advertisement daemon?

• router advertises default route
• hypervisors are delegated prefixes and then serve SLAAC to their VMs with no default route
• hosts get addresses via server SLAAC and default route from the real router

I hesitate to support anything tricky, especially since you also mention setting the destination MAC in the issue (which is something we can't do at this layer of the networking stack).

[skoef]

That actually works, never thought of that. The only difference with how I normally send the router advertisements is that now I have both a /64 route and a /48 route next to a default route in my routing table, but that doesn't harm anything.

The only hurdle I have to overcome now is to configure different prefixes for different source MAC/link-local addresses. I don't think such flexibility is currently possible in CoreRAD. For testing I configured 1 customer prefix and manually dropped all router solicitations from other MACs towards CoreRAD and that has the desired effect. How could I approach this issue?