DHCP server on a different subnet

[Alex Bligh]

Is it legal (i.e. conformant with the RFCs) for a DHCP server to send back
a DHCPOFFER / DHCPACK with a server identifier option, an IP source address,
and field si_addr (in short hand "the server IP address") all set to the
same value, but not on the same subnet as yiaddr (i.e. the offered DHCP
address), PROVIDED THAT a routers options is specified such that the
server is reachable via the router, and PROVIDED THAT it is reachable
at L2? (so to be clear, there is more than one subnet on the same
broadcast domain, so a 255.255.255.255 broadcast will still reach
the server).

As far as I can tell, this is (a) neither prohibited nor specifically
allowed in the RFCs, and (b) is no worse than a response from a dhcp relay
where si_addr and the server identifier may not be immediately reachable
(and it is si_addr rather than the others that are meant to be used).
The RFCs merely require si_addr to be reachable (which it is). This assumes
that when the server adds its IP address, it also adds its routers (as
opposed to setting the IP and netmask, then choosing to send a unicast
DHCPACK, and only after that setting its default gateway, which would
be pretty bizarre behaviour and which I think would break relay
configs)

What I am trying to do here is provide DHCP to a pile of /29s, and having
already "wasted" one for a gateway, network and broadcast, I don't want
to "waste" another for DHCP, and can't share the same IP as the router
for technical reasons.

Anyone know if I am likely to run into trouble here?

-- 
Alex Bligh