Handle route and other IP entries.

[frankcrawford]

Different question, have you ever considered expanding 95-radvd-gen to handle entries like route and RDNSS?

While I have a few thoughts, I haven't done anything to add it in so far.

[sshambar]

So you think there's a reliable way to determine DNS and routes that should be advertised dynamically? I'd think it'd be complicated to determine which routes from the gateway would be required as advertised routes... I've always statically configured them, so I'm assuming you're using routes acquired from DHCP (or similar)?

[frankcrawford]

Unfortunately I haven't really thought about it that far. The issue I was really looking at is if I get a new prefix from upstream being able to update the DMZ IF to add the update the internal route definition, i.e.

interface eth0 { prefix @prefix@ {....} }
interface eth1 { route @prefix-eth0@ {...} }

Where @prefix-eth0@ substitutes the prefix from interface eth0.

Of course you are correct that there are more routes on eth0 than just the one I want to update, hence it is more difficult.

Similarly for RDNSS IP just getting automatically updated to the new IP on the interface rather than having to modify the template.

[frankcrawford]

I've been thinking about this, and what I am considering is something that will allows updating of any entries that relate to the prefix on any specific interface, ignoring any other routes, as they should be able to be specified statically in the file.

So, within the template you can specify "@prefix-interface@" which will be replaced with the @prefix@ from interface @interface@. In fact similar to your prefix block it may duplicate that block, and works fine from route entries.

However, the one inconsistency here is that if you are dealing with RDNSS entries, it isn't duplicating the block, but rather the entry, i.e and entry like "RDNSS @prefix@::dead:beaf {};" would give "RDNSS YY::dead:beaf, ZZ:dead:beaf {};"

There are a few other places that IPv6 addresses are required, such as ABRO and within client and AdvRASrcAddress blocks, but all the examples I've seen seem to have them as link-local addresses, so would be unrelated to this usage.

interface eth0 { AdvSendAdvert on; @prefix@ { AdvOnLink on; AdvAutonomous on; }; RDNSS @prefix@::1 {}; }; interface eth1 { route @prefix-eth0@ { AdvRoutePreference medium; }; };

would give

interface eth0 { AdvSendAdvert on; prefix 2001:db8:0:1::/64 { AdvOnLink on; AdvAutonomous on; }; RDNSS 2001:db8:0:1::1 {}; }; interface eth1 { route 2001:db8:0:1::/64 { AdvRoutePreference medium; }; };